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Közeleg az év vége, és bár legtöb- 
bünk életében a falinaptár lecse- 
rélése tulajdonképpen semmiféle 
tényleges változást nem jelent, 
mégis bevett szokás, hogy ilyen- 
kor visszatekintünk az elmúlt 12 








hónapra, és megpróbáljuk meg- 
találni a hangsúlyos pontokat. 

A Linux esetében az ,év témájának" 
talán a szoftverszabadalmak -— tovább- 
ra is aktuális — ügyét tekinthetjük. 

A Linuxvilág alapvetően szakmai lap, 
így cikkeink túlnyomó többsége az ér- 
dekes műszaki lehetőségekkel, újítá- 
sokkal, valamint a kezdő felhasználók 
segítésével foglalkozik. Egy ilyen mé- 
retű ,vörös posztó" mellett azonban 
mi sem mehettünk el szó nélkül. Ép- 
pen ezért indítottuk útjára néhány hó- 
nappal ezelőtt Dr. Dudás Ágnes soro- 
zatát, amely közérthető bevezetést ad 
a témába, s így reményeink szerint 
elősegíti azt, hogy a szabad szoftverek 
alkotói és használói átlássák, pontosan 
milyen következményei is lehetnek 
annak, ha szabadalommal védenek 
például olyan műszaki megoldásokat, 
amelyeket bármely értelmes, konst- 
ruktív ember fél óra alatt képes kigon- 
dolni a sarokban üldögélve. 

Bízunk benne, hogy a tőkés társaságok 
egyre több területen érzékelhető és 
egyre nyilvánvalóbb világuralma nem 
terjed majd ki a szabad szoftverek vilá- 
gára is, holmi gazdasági érdekek miatt 
nem köti gúzsba a műszaki fejlődést, 
és nem kényszerít intellektuális illega- 
litásba eddig szabadon alkotó, és a köz 
érdekeit szolgáló embereket. 


Bár a többi témát sem hanyagoltuk el, 
és a szokásos sorozatok is folytatód- 
nak, ez évi utolsó számunk két leg- 
hangsúlyosabb témája a biztonság- 
technika és a PHP nyelv. Az előbbi 
témát három cikk is érinti. Szó esik 

a SELinux-ról, Mick Bauer folytatja 

a Linux fájlrendszerek biztonsági kér- 
déseinek tárgyalását, Hasnain Antigue 
pedig azt mutatja be, hogyan iga- 
zodhatunk el könnyen abban az 
adattengerben, amely egy komolyabb 
hálózat biztonsági átvizsgálása során 
keletkezik. 

A PHP 5 nyelv objektumközpontáú le- 
hetőségeinek használatáról Komáromi 
Zoltán kezdett el egy négy részesre 
tervezett sorozatot, Heilig (Cece) Sza- 
bolcs pedig a nyelv különleges lehető- 
ségeiről ír majd néhány cikket. 

És most lássuk a magyar szerzők so- 
rozatait! Fábián Zoltántól megtudhat- 
juk, hogyan tervezhetünk cégünk 
számára reklámsávot és logót a GIMP 
2.0 segítségével, Auth Gábor folytatja 
a FreeBSD bemutatását, Illés Viktor 
pedig a Linux és a mobil eszközök 
összeházasításának nehézségeit tag- 
lalja. Ebben a részben a grafikus felü- 
let beállításáról lesz szó. Garzó And- 
rás a hálózatok lelkivilágát tárgyló so- 
rozatának immár a 12. részénél tart, 
míg Beszédes Balázs a felhasználók 
lelkivilágának és viselkedésének vizs- 
gálati módszereit mutatja immár mű- 
szaki szempontból. 


Kellemes időtöltést, jó szórakozást 
kíván a Linuxvilág magazin csapata! 
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Programvadászat 


Decemberi korongunk legnagyobb ré- 
szét az Ubuntu Linux Live CD foglalja 
el. Ez egy Debian/GNU Linux alapú 
terjesztés. Mostanában szerencsére 
egyre többször bukkannak fel ilyen 
kiadások (ilyen például a KNOPPIX). 
A Debian előnyeit és hátrányait mérle- 
gelve a fejlesztők régóta érdemesnek 
találják azt arra, hogy a saját munkáik 
alapjául válasszák. Ez a sor a Storm 
Linux-szal kezdődött. Sajnos 

a Stormix Technologies Inc. körülbelül 
egy év után feladta a fejlesztést. A kö- 
vetkező nevező a Corel Linux volt. 
Mint a névből sejthető itt a Corel grafi- 
kai programokat gyártó cég állt a hát- 
térben azzal a céllal, hogy saját operá- 
ciós rendszert hozzon létre program- 
jaihoz. Nagyon jó eséllyel indultak, 

de végül ,lebeszélték" őket. Ezek után 
a Xandros vette a kezébe a Corel által 
elfelejteni akart terjesztést, amely 

a mai napig is létező kereskedelmi vál- 
tozat. Aztán a Progeny Linux követke- 
zett amely szintén nagyon ígéretesnek 
indult, de nem jött be a kereskedelmi 
számításuk. Ők is feladták, és inkább 
a tanácsadásra koncentrálnak. A Linux 
népszerűsítésében nagy szerepet ka- 
pott többek között a mi korongunkon 
is megjelent KNOPPIX Linux szintén 
Debian alapokon nyugszik, és ilyen az 
Ubuntu is. Az ok ami miatt a fejlesz- 
tőknek érdemes a Debiant alapnak vá- 
lasztani a hatalmas programarzenál, 
ami azonnal elérhető apt forrásban. 

A fenti felsorolás természetesen nem 
teljes, inkább csak rövid áttekintés. 


Az Ubuntu 

Az Ubuntu egy ősi afrikai szó jelenté- 
se: vagyok aki vagyok, mert minden- 
ki az aki". A fejlesztők szigorúan ve- 
szik azt a célt, hogy az Ubuntu mindig 
mindenki számára szabadon elérhető 
legyen. Nagy hangsúlyt fektetnek 

a nemzetköziségre, a programok és 
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ötlet, hogy a root fel- 
használó alapból tilt- 
va van. A telepítés 
során létrehozott 





juthasson el az [ezeforel őse dai 

Ubuntu". Hat hónapos a első felhasználó kap 
kiadási ciklussal szá- a sudo jogokat, vagyis 
molnak, és a megjele- , a root felhasználó jo- 
nő rendszert 18 hóna- uz gaival futtathat prog- 
pig támogatják, biz- ramokat a root jel- 
tonsági frissítésekkel szavának ismerete 


és hibajavításokkal. 
Ez hatalmas előny 
a Debiannal szemben. 


Bt 





Felhasználás 

Az Ubuntut használhatjuk asztali gé- 
peken vagy kiszolgálóként is. A jelen- 
legi kiadás az Intel x86, AMD64 és 
Power PC architektúrákat támogatja. 
Több mint 1000 programot használha- 
tunk azonnal. Van benne 2.6-os rend- 
szermag, a 2.8-as GNOME, és termé- 
szetesen minden feladathoz találunk 
megfelelő programokat, legyen szó 
akár böngészésről, irodai feladatok el- 
látásáról, webkiszolgálóról vagy játé- 
kokról. 


Erdekességek 

Az Ubuntu két változatban létezik. Van 
Live CD és telepítő CD, amelyek felépí- 
tésében természetesen vannak különb- 
ségek, Mindkettőt telepíthetjük, viszont 
a hardverfelismerés és az X felbontásá- 
nak kitalálása másként történik. Szá- 
momra nagyon érdekes és kifejezzen jó 


Current netwsck prokda:  . Uniknos 
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nélkül, ez biztonsá- 
gi szempontból elő- 
nyös megoldás. 
Következő számunkban bővebben 
írunk erről a terjesztésről. 








Korongunkon helyet kapott a szoká- 
sos Bitdefender frissítés is. Néhány 

a mostani cikkekhez tartozó csomag 
és forráskód az előző, tehát a 65. CD-n 
kapott helyet, mivel az Ubuntu Linux 
miatt most nem fértek volna fel. Ezek- 
nél a cikkeknél tehát nem elírás 

a 65. CD/Magazin kezdetű sor. 

Aki esetleg nem rendelkezik a Linux- 
világ előző számával az a cikkekhez 
tartozó anyagokat megtalálhatja 

a 5 melleklet.linuxvilag.hu címen is. 


Csontos Gyula 

(Csontos. GyulaOlinuxvilag.hu) 
A Linuxvilág szakmai és 
CD-szerkesztője. Szabadide- 
jében szívesen mászik 
hegyet és kerékpározik. 











Megnyíló Ingres 

A Computer Associates bejelentette, 
hogy Ingres r3 adatbázisát mind Linux, 
mind Windows operációs rendszerre 


Íngres8 


általánosan elérhetővé tette. A cég 
még augusztusban tette közzé az 
adatbázis-kezelő megnyitott forrás- 
kódját, amelynek további operációs 
rendszerekhez — 32 és 64 bites Sun 
Solaris, HP/UX és IBM AIX, továbbá 
HP Tru64 és OpenVMS - készített vál- 
tozatai idén és jövőre várhatók. Az 
Ingrest nagyjából egy évtizede az Ask 
Computer Systemstől vásárolta meg 

a CA, ám a jó nevű rendszer piaci ré- 
szesedése az utóbbi időben folyamato- 
san csökkent. A nyílttá tétellel a fel- 
használói tábor újbóli növekedését 
várják, nem is alaptalanul, hiszen au- 
gusztus óta több mint 15 ezer letöltést 
jegyeztek fel. 

5 opensource.ca.com/projects/ingres 


Pálfordulás 

Az Intel részéről is elismerték, a mega- 
hertzek kora véget ért: a cég törölte 
termékfejlesztési úti tervéből a 4 GHz 
órajelű Pentium 4 processzort. Az Intel 
hosszú ideig tartotta magát ahhoz 

a nézethez, hogy az órajel növelésével 
megfelelően fokozható a teljesítmény 
is — bár az új processzorszámozás be- 
vezetése arra utal, hogy talán maguk 
sem hittek az egészben. A legújabb fej- 
lemények szerint az Intel legnagyobb 
órajelű egymagos processzora a 3.8 
GHz-es lesz. Az órajel növelésének el- 
sősorban a hatalmas energiafogyasztás 
és hőtermelés állja útját, így a teljesít- 
mény fokozását a továbbiakban más 
módszerekkel kénytelenek megoldani. 
Ilyen például a gyorsítótár méretének 
növelése, ami ráadásul viszonylag 
könnyen kivitelezhető; a sokat emle- 
getett kétmagos processzorok beveze- 
tése valamint a 64 bitre való áttérés, de 
az Intel részéről a virtualizációs és biz- 
tonsági szolgáltatások bevezetését, bő- 
vítését is számba veszik, mint a , fel- 
használói élmény" fokozásának lehet- 
séges módját. Tétlenkedésre ugyanak- 
kor nincs idő, a versenytársak ugyanis 
már rendelkeznek 64 bites és kétmagos 
processzorokkal is, az Intelnek rövidebb 
távon is újdonságokkal kell előhoza- 
kodnia, ha meg akarja tartani vásárlóit. 


www.linuxvilag.hu 


Xen 2.0 

Elkészült a nagyteljesítményű virtuális- 
gép-alaprendszer, a Xen 2.0-s változata. 
A Xen fejlesztésének célja az, hogy 
egyetlen x86 alapú számítógépen közel 
natív sebességgel több operációs rend- 
szert is lehessen futtatni: a vendég ope- 
rációs rendszerek átültetett változatai- 
val dolgozva a teljes értékű számítógé- 
pet emuláló megoldásoknál sokkal 
jobb teljesítményt képes biztosítani, 
sőt, a felhasználók által észlelt teljesít- 
ménycsökkenés gyakorlatilag elhanya- 
golható ahhoz képest, mintha a számí- 
tógép natívan futtatná a vendég rend- 
szert. A Xen használatához a futtatni 





kívánt rendszermagokat ugyan módo- 
sítani kell, ám a változások a program- 
könyvtárakra és az alkalmazásokra 
már nem terjednek ki. A Xen jelenleg 
a 2.6.9-es és a 2.4.27-es Linuxot és 

a NetBSD-t támogatja, de a közeljövő- 
ben további rendszerek támogatását is 
megvalósítják. A Xen a Cambridge-i 
Egyetem nagy távolságú, elosztott adat- 
feldolgozó infrastruktúrák kiépítését 
célzó Xenoservers tervezetének egyik 
eleme, a jövőben olyan ígéretes szol- 
gáltatásokkal tervezik bővíteni, mint 
például a fürtkezelés, a processzorok 
közötti terheléselosztás és a többpro- 
cesszoros vendég rendszerek futtatása. 
3 www.cl.cam.ac.uk/Research/ 
SRG/netos/xen 


A bástyák ledőlnek 

A felröppent hírek szerint a Sharp ha- 
marosan kivonja az amerikai piacról 
linuxos Zaurus zsebtitkár modelljeit, így 
ezek kizárólag Japánban lesznek megvá- 
sárolhatók. A felmérések szerint a mo- 
biltelefon nélküli zsebtitkárok értékesí- 
tése a közeljövőben komoly csökkenés 
elé néz — sőt, a folyamat már be is in- 
dult —, az ilyen készülékek helyét egyre 
inkább az intelligens mobiltelefonok és 
a mindent egyben jellegű tenyérgépek 
veszik át. A kivonás mellett további érv 
lehet, hogy a linuxos zsebtitkárok a szű- 
kebb rajongói táboron túl nem nagyon 
nyerték el a vásárlók tetszéseit, a piacot 
továbbra is a windowsos és a Palm OS 
alapú termékek uralják. Nemrég a Sony 
és a Toshiba is hasonló döntést hozott. 
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Mobil. . . mi is? 

A Nokia bemutatta 7710-es típusú, 

a hagyományos mobiltelefonokra im- 
már a legcsekélyebb mértékben sem 





hasonlító telefonját. A szélesvásznú 
érintőképernyővel ellátott készülék ki- 
válóan példázza a mobiltelefonok és 

a zsebtitkárok összeolvadását. Kezelé- 
se utóbbiakhoz hasonlóan egy tollal 
történik, képességei pedig mindkét 
készülékcsoportot idézik: internetes 
böngésző, zene- és mozgóképlejátszó, 
1 MP felbontású kamera, EM rádió, 
MDP3 lejátszó, szövegszerkesztő, táblá- 
zatkezelő, személyi adatkezelő szol- 
gáltatások, kézírás-felismerés, képer- 
nyőn megjelenő billentyűzet. Termé- 
szetesen a legújabb és a jól bevált szol- 
gáltatások támogatása sem hiányozhat 
belőle, az internetre EGPRS vagy 
HSCSD összeköttetésen keresztül csat- 
lakozik, leveleinket pedig POP3, 
SMTP és IMAP protokollon keresztül 
egyaránt képes elérni. Alapmemóriá- 
jának mérete 90 MB, amit legfeljebb 
512 MB méretű MMC kártyával tu- 
dunk bővíteni. A 7710 Ázsiában már 
idén kapható lesz, míg Európában 
inkább csak húsvétra lephetjük meg 
magunkat vele. 

3 www.nokia.hu 


Gyorsuló Ultrastar 

A Hitachi Global Storage Technologies 
bemutatta Ultrastar 15K147 sorozatú, 
nagyteljesítményű, vállalati alkalma- 
zásokhoz szánt merevlemezeit. 

A 15000 1/perc fordulatszámmal üze- 
melő meghajtók a hasonló alkalmazá- 
sokban jelenleg leginkább elterjedt 
10000 1/perc fordulatszámú egysé- 
gekhez képest 33 százalékkal na- 
gyobb teljesítményt nyújtanak, el- 
érési idejük mindössze 2 ms, egyen- 
letes teljesítőképességükhöz pedig 

a 16 MB méretű, ma még szokatlanul 
nagy gyorsítótár is hozzájárul. A leg- 
újabb Ultrastarok 36, 73 és 147 GB-os 
kapacitással kaphatók, csatolófelüle- 
tük Ultra320 SCSI vagy 2 Gb/s sebes- 
ségű FC-AL lehet. 

3 www.hgst.com 
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Hidfőállás Budapesten 

Az indiai Satyam Computer Services új 
szolgáltató központot nyitott Budapes- 
ten. A cég hazánkból kedvező árfek- 
vésű — magyarul olcsó - szolgáltatá- 
sokat kíván nyújtani nyugat-európai 
ügyfeleinek. A Satyam Hungary 
Development Center az InfoParkban bé- 
rel irodát, eleinte 60 főt foglalkoztat, 
ám a későbbiekben a létszámot to- 
vábbi több százzal tervezik bővíteni. 
A budapesti letelepedés mellett két 
fontos érv szólt: a nyugat-európai 
ügyfelek közelsége és a jól képzett 
szakemberek viszonylagos olcsósága. 
Igaz, hogy egy indiai informatikus 
7500 dolláros átlagos keresetéhez ké- 


$atyam 
What Business Demands. 


pest egy magyar programozó 10500 
dollárt keres, ám ugyanezért a mun- 
káért Írországban 24500, az Amerikai 
Egyesült Államokban pedig 65000 
dollárt is kifizetnek. A Satyam nem 

az első itthon megtelepedő tanács- 
adó-szolgáltató cég, hasonló területen 
mozog a Tata Consultancy Services, 

az EDS és az IBM is. 

2 wwwi.satyam.com 


Gazdaságos zenék 

Az internetes zeneletöltések váratlan 
sikere egyre több szereplőt vonz erre 
a területre. A legújabb a hazánkban is 


TESCO 


jelen lévő Tesco, amely a 25 millió fon- 
tosra becsült angliai piacból szeretné 
kihasítani a maga szeletét. A Windows 
Media Playerrel együttműködő interne- 
tes áruházban több mint félmillió jó 
minőségű zeneszámot terveznek elér- 
hetővé tenni, a zeneszámok darabjáért 
79 pennyt, vagyis körülbelül 280 forin- 
tot kell majd fizetni. Ezzel az árral 

a Tesco viszonylag versenyképes lesz, 

a többi szereplő ugyanis — az iTunes 
kivételével -— vagy magasabb árat kér, 
vagy kisebb választékkal szolgál. 

3 www.tesco.com 





ONX: eladták, de marad 

A Harman International Industries beje- 
lentette, hogy november végi hatállyal 
felvásárolja a valós idejű operációs 


rendszeréről 
(ós ismert kana- 

dai ONX 
ONX SOFTWARE SYSTEMS Software 

Systemst. 


A ONX tészéről érkezett nyilatkozatok 
szerint a két cég termékei kiválóan ki- 
egészítik egymást, a Harman ugyanis 
hangrendszereket és telematikai elekt- 
ronikus készülékeket gyárt az autó- 
ipar számára, míg a ONX beágyazott 
operációs rendszerével komoly beszál- 
lítói eredményeket ért el ezen a terüle- 
ten. A Harman állítólag meghagyja 

a ONX fejlesztői részlegének önálló- 
ságát, sőt, az operációs rendszer 

a Harman versenytársai — ilyen 

a Delphi és a Visteon — számára is meg- 
vásárolható marad. A Harman egyéb- 
ként több mint egymilliárd dollár ér- 
tékben szállít autós rendszereket töb- 
bek közt a Chryslernek és a Mercedes- 
Benznek, mellette egészen eltörpül 

a mindössze 25 millió dolláros bevételt 
felmutató ONX. A felvásárlás ugyan- 
akkor rámutat, hogy az autóiparban 

is egyre nagyobb szerephez jutnak 

a szoftverek, márpedig az autógyárak 
is átfogó megoldásokat várnak beszál- 
lítóiktól. 

2 www.harman.com 

2 www.gnx.com 


Kiképzés 

Mácrciusig a Novell több mint 500 
platina szintű - illetve, ha ők 

nem töltik meg a felkínált helyeket, 
akkor arany szintű - értéknövelő 
viszonteladójának ingyenes Novell 
Certified Linux Professional képzést 
biztosít. Az új minősítő program 

a Novell SuSE Linux Certified 
Professional programjának megújí- 
tott változata, amely a közeljövőben 
fokozatosan átveszi elődje helyét. 

A novemberben induló tanfolyam- 
ok öt naposak, díjuk normál esetben 
kereken hatezer dollár. 

2 www.novell.comltraining/certinfo/cip 


Medgyesi Zoltán 
(mzerettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 














Mi újság a rendszermag fejlesztése körül? 





A Red Hat képviselői úgy döntöttek, hogy az általuk 
nemrég megvásárolt Global Filesystem (GFS) fürtö- 
ző fájlrendszert GPL hatálya alatt teszik elérhetővé. 
A tervezet múltja meglehetősen kalandos. Először 
mint a Sistina GPL-es fejlesztése indult, ám a cég 
2001-ben Sistina Public License hatálya alá helyezte 
át, ami a forráskód továbbadását díjfizetéshez kötöt- 
te. A döntést hatalmas felzúdulás követte, többek 
közt Alan Cox is kifogásolta, hogy a szerződésváltás 
saját szerzői jogait is sérti, hiszen maga is hozzájá- 
rult a GFS fejlesztéséhez. Elindult az OpenGFS Pro- 
ject, amely a Sistina-féle kód utolsó GPL hatálya 

alá tartozó változatára épült. A következő években 

a Sistina megpróbálta saját termékeként terjeszteni 
a GFS-t, 2003-ban még a CommvVaulttal is szövet- 
ségre lépett. 2004-ben a Red Hat megvette a kódot 
a Sistinától, és most újra GPL hatálya alatt jelentette 
meg. Annak idején, 2000-ben a GFS jó eséllyel be- 
kerülhetett volna a hivatalos Linux rendszermagba. 
Most, hogy újra elérhető, a Red Hatis támogatja 

a beépítését. Jelenleg úgy néz ki, hogy a kód sza- 
bad marad. 


Linus Torvalds új folttulajdonlási rendszerre tett ja- 
vaslatot, amely a jelek szerint egyelőre sikeres is. 

A cél, ahogy ő mondja az, hogy a rendszermag fej- 
lesztői esetleges szerzői jogsértésre vonatkozó vád 
esetén követhessék a foltok sorsát. Linus indokai 
egyértelműek. Ő és segítői rengeteg időt fordítottak 
arra, hogy a The SCO Group szerzői jogsértésre vo- 
natkozó vádjait elhárítsák. Ehhez - legalábbis ed- 
dig — ősrégi levelezési listák anyagán kellett átrágni- 
uk magukat. A Linus által javasolt tulajdonlási rend- 
szer, ami úgy tűnik, rövid egyeztetések után széles 
körű alkalmazásra kerül, mindössze annyit tesz szük- 
ségessé, hogy a fejlesztők feltüntessék nevüket 

a foltokban, és jelezzék egyetértésüket a rendszer- 
magra vonatkozó szerződéssel. Minden foltban sze- 
repelni fog minden olyan fejlesztő neve, aki a rend- 
szermagba való bekerülése előtt módosította. Ezzel 
a megoldással a szerzői jog későbbi állítólagos 
megsértéseit csupán a foltok áttekintésével ki lehet 
vizsgálni, és nem lesz szükség arra, hogy a foltok 
történetét a levelezési listák bújásával próbálják 
visszakövetni. Írásom születésekor sok fejlesztő már 
használja az új rendszer, szerencsére eddig nem volt 
szükség az Így összegyűjtött adatokra. 


Randy Dunlap továbbfűzte az a meglehetősen régi 
ötletet, amely szerint a .config adatokat fordítás 
után magába a rendszermagba kellene elmenteni. 
Szerinte a rendszermag változatszámát, továbbá 

a fordítás dátumát is fel kellene jegyezni. A .config 
adatok rendszermagba való mentésének ötlete an- 
nak idején sok vitát váltott ki, hiszen ezeket a rend- 
szermagon kívül is megfelelően tárolni lehet. Mivel 


e tekintetben sikerült egyezségre jutni, Randy újabb 
adatok beépítésére vonatkozó javaslata jóval kedve- 
zőbb fogadtatásra talált. Sőt, több fejlesztő is meg- 
jegyezte, hogy az ötletet már jóval korábban meg 
kellett volna valósítani. Úgy látszik, az emberi termé- 
szet alapvető jellegzetessége, hogy még a legnyil- 
vánvalóbb dolgokat is fel kell fedeznie valakinek. 


A Jeff Dike-féle User-Mode Linux (UML) műszaki ne- 
hézségek miatt nehézkesen halad a hivatalos 2.6-ös 
rendszermagfa részévé válás irányába. Látszólag 
Andrew Morton több mint boldogan fogadja Jeff 
foltjait, csakhogy Jeffnek gondjai vannak a foltok el- 
fogadható darabokra osztásával. Jeff maga is beval- 
lotta, hogy az UML-es munka kapcsán , kiszúrt ma- 
gával", ugyanis nem tudja, milyen eszközökkel ke- 
zelhetné a folt felosztását. Az UML folt annyira 
nagyra nőtt, hogy feldarabolása komoly kihívássá 
vált. A nagyobb bővítésekkel általában ez történik. 
Sokszor szükségtelenül sok energiát fordítanak 

a folt beépítésének előkészítésére, végül amikor 

a fejlesztők elérkezettnek látják az időt, hirtelen rá- 
döbbennek, hogy még rengeteg egyéb munka áll 
előttük, és a folttal még nem is foglalkoztak. A vége 
természetesen végeláthatatlan vitatkozás. Jeff szá- 
mára nem újak a felmerülő kérdések, de hiába van 
tisztában a teendőkkel, ha a foltokat rendkívül nehéz 
egy-egy feladatot ellátó apró részekre osztani. Az 
biztos, hogy az UML be fog kerülni a 2.6-os rend- 
szermagba, de a nehézségek miatt komoly csúszás- 
ra kell számítani. 


A CREDITS fájl karbantartását sokáig John A. Martin 
végezte, és tevékenységéért a MAINTAINERS fájlban 
is elismerésben részesült, ám most úgy látszik, hogy 
a CREDITS fájl önkarbantartóvá vált, külön gondozá- 
sára nincs többé szükség. Linus Torvalds, Andrew 
Morton és a rendszermag többi karbantartója gyakor- 
latilag átvették ezeket a feladatokat, a fejlesztői foltok 
sokszor saját frissítést tartalmaznak a CREDITS fájl- 
hoz, ami annak külön bővítését szükségtelenné teszi. 
A CREDTITS fájllal tehát egyszerűen az történt, hogy 

a rendszermag fejlesztésének teljes jogú részévé vált. 
Annak idején, első összeállításakor meglehetősen 
csüggesztő feladat volt a fájlt gondozni, ugyanis na- 
gyon sok hozzájáruló neve kimaradt belőle. Most, 
hogy önfenntartóvá vált, tartalma is lényegesen pon- 
tosabb. John úri eleganciával lépett le, amikor Adrian 
Bunk rámutatott, hogy karbantartói munkája immár 
felesleges, ugyanakkor azt még megjegyezte, hogy 
ha a jövőben újra szükség volna a segítségére, akkor 
kész ismét munkába állni. 


Zack Brown 
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LT EZTTTTA GT 4 


Linux 101 

A klasszikus IBM billentyűzetek 
felépítésén alapuló, testreszabott 
billentyűzeteket gyártó és javító 


ve FTÉBHÉTTE 
en sére 
file ket 


cég, az UniComp bejelentette 

a Linux 101 billentyűzet megjele- 
nését. A Linux 101 egy programo- 
zott billentyűzet, ami a Linux fel- 
használók számára a kényelme- 
sebb elérhetőség érdekében 
átrendezi a Ctrl, Caps-Lock és 
Esc billentyűk elhelyezkedését. 

A Linux 101 billentyűzet kapható 
az alapjaként szolgáló IBM M 
modellből származó , buckling 
spring" mechanikával, vagy 

a csendesebb gumimembrános 
felépítésben. Az UniComp honlap- 
járól letölthetőek az egyes elren- 
dezéseket bemutató PDF-fájlok. 
www.pckeyboard.com 





NetDirector Linux 
Configuration Suite 

Az Emu Software cég NetDirector 
Linux Configuration Suite prog- 
ramcsomagja egy méretezhető 
többkiszolgálós felhasználásra ter- 
vezett vezérlőeszköz, amely ve- 
gyes linuxos környezetben képes 
a különböző gyártóktól származó 
és eltérő tevékenységeket végző 
kiszolgálók hálózatának összefo- 
gására. A NetDirector csomag 
elhasználói felületén keresztül 

a rendszergazda központilag fel- 
ügyelheti az Apache, Samba, 
DNS, DHCP FTP vagy levelezés 
szolgáltatásokat nyújtó kiszolgá- 
ók működését. Lehetőség van 

a kiszolgálók szervezetek, földrajzi 
elhelyezkedés, vagy a kiszolgálón 
utó alkalmazás szerinti csoporto- 
sítására és kezelésére. Az intézke- 
dések ezután alkalmazhatók a tel- 
jes csoportra, vagy az elrendezés 
meghatározott kiszolgálójára. 
wwww.emusoftware.com 





Enea Orchestra 

Az Embedded Linux és az Enea 
cég szigorúan valósidejű (hard 
real-time) operációs rendszere ké- 


Linuxvilág 


pezi az alapját az Enea Orchestrá- 
nak, ennek a magas rendelkezés- 
re állással rendelkező távközlési 
és adatkommunikációs progra- 
mok számára készült programfe- 
lületnek. Az Enea Orchestra lehe- 
tővé teszi a távközlési és adat- 
kommunikációs készülékek gyár- 
tói számára, hogy magas rendel- 
kezésre állással és nagy hibatű- 
réssel rendelkező többprocesszo- 
ros programrendszereket helyez- 
zenek üzembe. Az Orcestra tartal- 
mazza a Metrowerks Corporation- 
től származó beágyazott fejlesztői 
technológiát, amely egyszerűsíti 
a rendszermag ellenőrzését, az 
áramköri kártyák hibáinak felmé- 
rését, az alkalmazások létrehozá- 
sát és tesztelését. Az így létrejövő 
programok futtathatók bármilyen 
Linux-változaton, az OSE alatt, 
vagy a kettő valamilyen kombi- 
nációján. Az Enea Orchestra elő- 
fizetői rendszerben hozzáférhető 
és tartalmazza az alkalmazás- 
fejlesztői és a felületfejlesztői 
csomagokat. 

www.enea.com 


Motorola A780 


A Motorola A780 mobiltelefonjá- 
nak alapját a Linux és Java prog- 
ramok képezik. A lenyitható for- 





májú telefon szolgáltatásai közt 
egyebek mellett megtaláljuk 

a PDA-szerű, egynegyed VGA-kép 
megjelenítésére képes (240 x 320 
képpontos) színes érintőkijelzőt, 
a Bluetooth hálózati és szinkro- 
nizációs szolgáltatást, egy 1,3 
megapixeles digitális fényképező- 


gépet, MP3 lejátszót, 48 MB 
memóriát vagy eltávolítható 
TransFlash tárólót. Az A780 négy- 
sávos GSM telefon, így támogatja 
az elterjedt amerikai és nemzetkö- 
zi frekvenciákat. A telefon tartal- 
mazza az EDGE technológiát is, 
amely akár 240 Kbps sebességű 
Internetes elérést biztosító adatát- 
vitelt is lehetővé tesz. 
www.motorola.com 


EtherDrive tárolókártyák 


A Coraid cég piacra dobta az 
EtherDrive Storage Blades nevű 
tárolókártyáit, amelyek méretez- 





hető hálózatos blokktároló létre- 
hozását teszik lehetővé az AoE 
(ATA-over-Ethernet) protokollt 
használó kiszolgálók számára. 

Az EtherDrive tárolókártya a szab- 
ványos ATA meghajtókat fogja 
össze egységes, rugalmasan 
alkalmazható, keretekbe szerel- 
hető tárolóegységgé. Minden 
EtherDrive tartalmaz saját 
Ethernet csatolót és nanokiszol- 
gálót, amelyek az Ethernet-ATA 
protokoll-átalakítást végzik. Az 
EtherDrive meghajtók 250 GB-tól 
16 petabájt méretig terjedő meg- 
osztott tárolási kapacitású egysé- 
gek létrehozását biztosítják. Egy- 
aránt hozzáférhető a szabványos 
2,5 vagy 3,5 colos ATA meghaj- 
tókkal. A Linux 2.4 és 2.6 rend- 
szermagokhoz már forráskód- 
ban hozzáférhetőek GPL licencű 
meghajtók, egyéb operációs 
rendszerekhez pedig hamarosan 
elkészülnek. 

www.coraid.com 


Ouadputer-Navion 

A Microway cég Ouadputer- 
Navion nevű gépe egy SMP 
(Symmetrical Multi-Processing, 
szimmetrikus többprocesszoros) 
kiszolgáló négy AMD Opteron 
850 processzorral, amely SuSE 
Linuxot futtat. A 4U készülékház- 
ban elhelyezkedő Ouadputer- 











Új termékek 





Navion 810 wattos redundáns, 
hot-swap (menet közben cserél- 
hető) tápegységgel rendelkezik, 
és lehetővé teszi 18 darab 
SATA/IDE vagy 5 darab SCSI meg- 
hajtó beépítését. A processzorok 
működési frekvenciája 2,2 GHz és 
támogatják a HyperlTransport 
technológiát. 

A 2,5" méretű eszközökkel akár 
1,36 TB tárolókapacitású beépí- 
tett RAID-rendszer hozható lét- 
re. A konfiguráció tartalmazza 

a Microway Nodewatch és 
MCMNS hardver- és szoftver-kezelő 
eszközeit amelyek lehetővé teszik 
a fürtözött gépek távoli ellenőrzé- 
sét és vezérlését. 
www.microway.com 


SC-4400 FlashDisk OpenRAID 
A Winchester Systems bejelentet- 
te a FlashDisk OpenRAID-et, 
amely egy akár öt különböző típu- 
sú kiszolgáló támogatására is ké- 
pes adattároló tömb. A kiszolgálók 
a tárolóeszközökön U160 SCSI 
protokoll segítségével osztoznak, 
a rendszer legfeljebb 2.3 TB tár- 
hely kezelésére képes. További 
bővítő készülékház hozzáadásával 
a FlashDisk OpenRAID 4.6 IB ka- 
pacitásig méretezhető, legfeljebb 
három állomással. Támogatja 

a kettős, redundáns, 64 bites 
RAID-vezérlőket, és különféle a le- 
mezeket erősen terhelő feladatok- 
hoz használható, például adatbá- 
Zisok kezelésére, multimédiás al- 
kalmazásokhoz, elektronikus leve- 
lezési vagy webkiszolgáló rend- 
szerekhez. Az SC-4400 minden ki- 
szolgáló operációs rendszerrel ké- 
pes együttműködni, a gazdaolda- 
lon illesztóprogramot nem igényel. 
www.winsys.com 
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CommuniGate Pro 4.2 

A 4.2-es változat megjelenésével 
a CommuniGate Pro Real-Time 
Communications immár bizton- 
ságos azonnali üzenetküldést, 
VolP-támogatást, videokonfe- 
rencia lehetőséget, rajztábla- 
megosztást, valamint asztal- és 
alkalmazásmegosztási lehetősé- 
get egyaránt biztosít. A szabvá- 
nyokra alapuló, többféle géptípu- 
son való használatot célzó felépí- 
tésnek és a SIP protokollnak kö- 
szönhetően a CommuniGate Pro 
4.2 tetszőleges ügyfélen futtat- 
ható, akár az irodában, akár tá- 





volról, UNIX, Linux, Mac OS X és 
Windows operációs rendszeren. 
Ugyancsak a 4.2-es változat új- 
donsága a teljes mértékben 
testreszabható webes felület és 
a webes levelezési és naptárke- 
zelési lehetőség. Mindemellett 
a CommuniGate Pro 4.2 hibael- 
hárítási, karbantartási célokra 
használható távoli felügyeleti 
szolgáltatásokat is biztosít. 
www.stalker.com 


Wyse Winterm 5150SE 

A Wyse Winterm 5150SE egy 
Wyse Linux V6 operációs rend- 
szerre és AMD Geode GX 533 
processzorra épülő vékony ügy- 
fél. A Wyse Linux V6 a 2.6-os 
Linux rendszermagra alapul, 
testreszabási lehetőségei révén 
számos különböző környezetben 
képes megfelelni az igényeknek, 
ide értve a Windows, a UNIX, 

a Linux, az IBM, az X-Window 
és a Java alapú rendszereket. 

A Winterm 5150SE szabad 
munkaállomás-váltási lehetősé- 
get kínál, vagyis a felhasználók 
bármelyik ügyfélre bejelentkez- 
hetnek, beállításaik bárhol elér- 
hetők maradnak. Az 5150SE 


moduláris felépítésének kö- 
szönhetően a szükséges bőví- 
tések könnyedén elvégezhetők. 
A vékony ügyfél csak olvasha- 
tó fájlrendszerrel rendelkezik, 
mozgó alkatrészeket nem tar- 
talmaz, kisméretű készülékháza 
pedig USB és hagyományos 
be/kiviteli kapukkal egyaránt 
rendelkezik. 

Www.wyse.com 


Atigo felölthető számítógépek 
A Xybernaut bejelentette, hogy 
Atigo vezeték nélküli panelgépei 
már Linuxszal is elérhetők. Az 
Atigo gépek vezeték nélküli, lapos 
képernyős számítógépekként 
vagy önálló, vezeték nélküli kap- 
csolatok kezelésére képes mo- 
bil/felölthető számítógépeként 
használhatók. Az Atigok támogat- 
ják a kettős használatot, az IEEE 
802.11b szabvány szerinti vezeték 
nélküli hálózatokat normál PC-kár- 
tya és/vagy CompactFlash kártya 
segítségével érik el. A linuxos 
Atigok nyílt forrású támogatási, 
adatátviteli, adatkezelő és rend- 
szerbeállító segédeszközöket is 
tartalmaznak. Az Atigo T modell 

1 GHz órajelű Crusoe TM5800 
processzort és 256 MB SDRAM 
memóriát tartalmaz, Flash memó- 





riája 128, 256 vagy 512 MB vagy 
1 GB méretű lehet. Minden Atigo 
belső, újratölthető lítium-ion akku- 
mulátorral rendelkezik, de üzem 
közben cserélhető külső akkumu- 
látorokkal is használható. A gépek 
mindegyike 8,4"-es, 800 x 600 
képpont felbontású SVGA kijelző- 
vel rendelkezik. 
www.xybernaut.com 


Linux Journal 2004. 126. 
és 127. szám 


2004. december 11 


Láttuk-hallottuk 


0 Kiskapu Kft. Minden jog fenntartva 








ETTÉK TT A 


1. A linuxos kiszolgálók kínai piacának a következő öt évre 
vetített százalékos növekedése: 49,3 


LT LÉT 





2. Azoknak a fejlesztőknek a száma, akik rendszeresen 
nyújtanak be módosításokat a Linuxhoz: 1000 


3. A fentiek ekkora százaléka kap fizetséget munkaadójától 
linuxos hozzájárulásáért: 10 


fh 


4. Az utolsó 38000 Linux-módosítás ekkora százalékát 
adják a fizetett fejlesztők: 974 
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5. A Linuxhoz kapcsolódó termékek és szolgáltatások 
piaca 2003-ban, milliárd dollárban: 2.5 


6. A Dice.com webhelyen szereplő számítástechnikusi 
állások becsült száma: 49 


7. A Dice.com ajánlatai közül körülbelül ennyiszer 
száz számítástechnikusi álláshoz kellenek linuxos 
ismeretek: 22 


8. Az elmúlt évhez képest ez az érték ennyi százalékkal 
nőtt: 190 


9. A Dice.com ajánlatai közül ennyi számítástechnikusi 
álláshoz kellenek linuxos vizsgák: 10 


10. Az Apache helyezése a Netcraft webkiszolgálókra 
vonatkozó felmérésében: 1 


11. Az Apache százalékos részesedése az utolsó felmérés 
szerint (2004 augusztusa): 67,37 





Források 


1: CCID Consulting, az Oracle 
közreműködésével 


2-4: Andrew Morton 


5: Morgan Reed, Association for Competitive 
Technology 


6-9:  Computerworld 
10, 11:  Netcraft, Ltd., 5 netcraft.com 
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Nem lesz 2.7-es rendszermag? 


Felejtsünk el mindent a rendszermagok páros-páratlan számozásáról. 


2004-es Linux Kernel Summit rendezvényen 
A a rendszermag vezető fejlesztői bejelentették, 

hogy a 2.7-es fejlesztői rendszermag a közeljövő- 
ben nem jelenik meg. Úgy nyilatkoztak, hogy megfelelt 
nekik a dolgok eddigi menete, és nem akartak változtatni 
rajta. Mivel a bejelentés rengeteg félreértést okozott, meg- 
próbálom elmagyarázni, mi is történt. 
A 2.5-ös rendszermag fejlesztése közben a felső szintű kar- 
bantartási folyamatok megváltoztak. Mielőtt Linus elkezdte 
volna használni a BitKeeper változatkövető rendszert, a kar- 
bantartók egyszerre 10-20 foltot is küldtek neki, majd meg 
kellett várniuk a következő kiadást, csak akkor derült ki, 
hogy kódjuk bekerült-e a rendszermagba. Ha nem, újra kel- 
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lett próbálkozniuk. Ez a rendszer több mint tíz éven keresz- 
tül remekül megfelelt. A 2.5-ös sorozat fejlesztésének meg- 
kezdése után hatalmas perpatvar kerekedett a kihagyott 
foltok miatt, ami azzal végződött, hogy Linus a BitKeeper 
használata mellett döntött. Miután a BitKeeper fejlesztőivel 
nem kis munkát fektettek a rendszermag fejlesztői által igé- 
nyelt szolgáltatások megvalósításába, Linus a 2.5.3-as rend- 
szermag 2002. február 2-i kiadásakor bejelentette 

a Bitkeeperre való áttérést. A fejlesztők túlnyomó részének 
munkája semmit sem változott. Továbbra is elküldték kód- 
jaikat a felsőbb szintű karbantartóknak, majd vártak. A kar- 
bantartók egy kis részének, akik a BitKeeper használata 
mellett döntöttek, azonban gyökeresen átalakult az élete. 
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Nekik létre kellett hozniuk egy BitKeeper fát, fel kellett töl- 
teniük a Linusnak szánt módosításokkal, majd jelezniük 
kellett neki. ő átemelte a foltokat saját fájába, és elrendezte 
a mások munkáival kialakuló kisebb ütközéseket. 

A Bitkeeper használatának nem várt következményei is 
voltak. Először is, bármely pillanatban bárki figyelemmel 
követhette Linus fájának állapotát. Néhány fejlesztő, köz- 
tük Peter Anvin és Jeff Garzik megoldották, hogy az éjjelen- 
kénti pillanatfelvételek a kernel.org-on is megjelenjenek. 

A Bitkeeper fejlesztőivel együttműködve CVS és Subversion 
tárolókat is készítettek a változatkövető rendszert hasz- 
nálóknak. 

A fa aktuális állapotának ismerete lehetővé tette, hogy 

a karbantartók gyorsabban eljuttassák foltjaikat Linusnak, 
továbbá azt is láthatták, hogy mikor fogadta el őket. Nem 
kellett két hetet várni egy-egy pillanatfelvételre, azonnal 
el lehetett küldeni a módosításokat. A rendszermag fej- 
lesztése azonnal felgyorsult. 

Másodszor, minden Linus fájába bekerült foltról értesítés 
ment egy levelezési listára, ennek segítségével bárki követ- 
hette a változásokat. A fejlesztők figyelemmel kísérhették 
a rendszermag tetszőleges részét érintő módosításokat, 
megtudhatták azok okát, és rámutathattak az esetleges 
problémákra. A lista révén javult a kölcsönös ellenőrzés, 

a hibákat hamarabb jelezni lehetett, az egyes fejlesztési te- 
rületekkel kapcsolatosan pedig mindenki naprakész infor- 
mációkkal rendelkezhetett. 


Végül elkészült a 2.6 

A rendszermag fejlesztői 2002. december 31-én jelentet- 

ték be a 2.6-os sorozat szolgáltatáskészletének befagyasz- 
tását. 2003. július 7-én napvilágot látott az első 2.6.0-test1 
rendszermag, a karbantartási folyamat pedig újfent átala- 
kult. Linus helyett Andrew Morton fogadta szinte az összes 
foltot. A BitKeepert használók fáit viszont továbbra is köz- 
vetlenül Linus vette át. Végül 2003. december 17-én meg- 
jelent a 2.6.0-s rendszermag — a 2.5-ös és a 2.6-os változat 
fejlesztésének 680 napja alatt óránként átlagosan 1,66 
módosítást végeztek el. 

A 2.6.x sorozat következő öt tagját nagyjából havonta adták 
ki, mindegyik kiadás 538-1472 módosítás eredményeként 
született meg. Ezután a 2.6.5-ös változattal felgyorsultak 

a dolgok, a 2.6.6-os változat 1757, míg a 2.6.7-es 2306 módo- 
sítás nyomát viselte magán. A 2.6.0 - 2.6.7 időszakban az 
üzembiztos rendszermag óránként átlagosan 2.2 foltot ol- 
vasztott magába, vagyis gyorsabban változott, mint a fej- 
lesztői változat. A 2.6.7-es ugyanakkor számos teljesítmény- 
mérés és teszt szerint minden idők legstabilabb Linux rend- 
szermagja volt. 

Talán a fejlesztők megbolondultak, és csak úgy, kényük-ked- 
vük szerint kezdtek el ellenőrizetlen kódrészleteket kiadni? 
Nem. A 2.6-os sorozatban Andrew Morton továbbra is ellen- 
őrzött minden benyújtott foltot, mielőtt továbbadta volna 
őket Linusnak. A BitkKeepert használó fejlesztők továbbra is 
Andrew fájában ellenőrizhették foltjaik állapotát, és ha nem 
merült fel semmi gond, Linustól kérhették elfogadásukat. 

A módosításokat tehát jelenleg a -mm fa felhasználói ellen- 
őrzik. Ez teljesen eltér a dolgok korábbi menetétől. Jelenleg 
a foltok ellenőrzését, fordítását, jó és rossz célú felhasználá- 
sát a földkerekség felhasználói végzik, mielőtt véglegesen 
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elfogadnák őket. Ha egy folttal vagy foltok egy csoportjával 
valamilyen gond van, Andrew egyszerűen kidobja őket sa- 
ját fájából, és felkéri az eredeti fejlesztőt a javításra. 

Mivel lehetőség nyílt arra, hogy a foltok szélesebb körű 
tesztelésen essenek át, mielőtt a fába bekerülnének, a 2.6-os 
sorozat fejlesztésének folyamata a következőkből fog állni: 
Linus kiadja a következő 2.6-os rendszermagot. 

A karbantartók elárasztják Linust a -mm fában már kipró- 
bált foltokkal. Néhány hét elteltével Linus kiad egy -rc 
rendszermag-pillanatfelvételt. 

Mindenki megpróbál magához térni a változtatások özöné- 
től, majd kijavítani a -rc rendszermagban talált hibákat. 
Néhány héttel később megjelenik a következő 2.6-os rend- 
szermag, és a folyamat újrakezdődik. 

Előfordulhat azonban, hogy túl sok változás áll be ahhoz, 
hogy kezelni lehessen őket, ekkor akár a 2.7-es rendszer- 
mag ág létrehozására is sor kerülhet. Ezt Linus feladata 
megtenni, az új, még kipróbálatlan foltok ebbe a fába kerül- 
nének. Ezután, amint a 2.7-es rendszermag üzembiztossá 
válik, sort kerít a 2.6-ost érintő, folyamatban lévő módosítá- 
sok átvételére a 2.7-esbe. Ha úgy ítéli meg, hogy a 2.7-es 
rendszermag fejlesztése rossz irányt vett, akkor a 2.7-est tö- 
rölni fogják, és mindenki a 2.6-os fán fog tovább dolgozni. 
Ha a 2.7-es fa stabillá válik, akkor vagy visszakerül a 2.6- 
osba, vagy megkapja a 2.8-as számot. 

A sok bonyodalom oka az, hogy a rendszermag fejlesztői 

a jelenlegi helyzetben kiválóan együtt tudnak működni. 

A komolyabb változások, mint például a 8 kB-os rend- 
szermagvermek bevezetése a 4 kB-os helyett, az üzembiz- 
tos sorozatot érintik. A felhasználók így viszonylag hamar 
igénybe vehetik a legújabb szolgáltatásokat. A terjesztések 
készítői üzembiztosabb rendszermagokat biztosíthatnak 
ügyfeleiknek, hiszen nincs szükség arra, hogy a fejlesztői 
ágból külön munka árán átemeljék a foltokat az üzembiztos 
ágba, ahogy azt a 2.5-ös sorozatnál is láttuk. 

A gyorsabb fejlesztés miatt a rendszermagon belüli API 
gyakorlatilag folyamatosan változik. A Linux esetében 

ez nem újdonság, ám most még nagyobb hangsúlyt kap. 

A fő kernel.org fában nem szereplő rendszermagmodulok 
tehát rendkívül gyorsan működésképtelenekké válhatnak. 
Fontos tehát, hogy ezek a modulok megtalálhatók legye- 
nek a fő rendszermag fában. Így az API-ra vonatkozó 
módosításokat az érintett modulokban is végrehajtják, és 
minden felhasználó élvezheti a modulok által biztosított 
szolgáltatásokat. 

A folyamat valójában nem hirtelen változott meg, inkább azt 
mondhatjuk, hogy lassacskán kifejlődött valami kiválóan 
működő dolog - sőt, a rendszermag fejlesztőinek közössé- 
gén kívüli sokan talán észre sem vették, hogy bármi is válto- 
zott, egyszerűen csak rádöbbentek egy nap, hogy minden 
korábbinál jobb Linux rendszermag fut a gépükön. 


Linux Journal 2004. november, 127. szám 


Greg Kroah-Hartman (gregckroah.com) 

Jelenleg a Linux-rendszermag különféle 
illesztőóprogram-alrendszereiért felelős. Az IBM-nél 
dolgozik és a Linux-rendszermaggal kapcsolatos 
kérdésekkel foglalkozik. 














Gyors alkalmazásfejlesztés Python és Glade 


használatával 


A Glade segítségével könnyedén elkészíthetjük és módosíthatjuk Python 
alkalmazásaink grafikus felületét, sőt, még az eseménykezelők létrehozását 


is önműködővé tehetjük vele. 


grafikus programok készítése két lépésből áll. 
A Először meg kell írni a felületet létrehozó kódot, 

amely megjeleníti a különféle kezelőelemeket, 
menüket, gombokat, feliratokat. Ezután el kell készíteni az 
események bekövetkezésekor — például gomb lenyomása- 
kor vagy menüelem kiválasztásakor - lefutó kódrészlete- 
ket. A program elinduláskor egy eseményhurokba lép be, 
várja az eseményeket, majd gondoskodik a megfelelő ese- 
ménykezelő meghívásáról. Ezt az adott eseményhez tarto- 
zó visszahívó függvénynek, röviden visszahívónak neve- 
zünk. Kell például írnunk egy olyan függvényt, amely 
a gombok megnyomásakor fut le. A kezelőelemek megjele- 
nítését végző kód megírása, az eseménykezelő függvények 
megadása és az eseményeknek a függvényekhez való csa- 
tolása túlságosan hosszadalmas és unalmas munka ahhoz, 
hogy kézzel végezzük el. 
Sok kezelőelem-készlethez létezik olyan eszköz, amellyel gra- 
fikus felületen állíthatjuk össze programunk felületét. Damon 
Chaplin Glade néven készített egy ilyent a GTKAGNOME 
készlethez. Ezzel nemcsak a kezelőfelület képét alkothatjuk 
meg, hanem egyszerűen adhatjuk meg vele az egyes ese- 
ménykezelő függvényeket is. A Glade a kezelőelemeket és 
a visszahívókat egy XML fájlban tárolja, végeredményként 
pedig olyan C vagy C-t - programot állít elő, amely a kezelő- 
elemek megadott elrendezésének megfelelő hívások mind- 
egyikét tartalmazza, továbbá létrehozza a visszahívók kapcso- 
latait és magukat az üres visszahívókat is. 
Maga a Glade sajnos nem használható Python kód létreho- 
zására, az általam írt GladeGen azonban a Glade XML fájl 
alapján Python kódot készít. 
Ha megváltoztatjuk a grafikus felületet a Glade-del, akkor a fe- 
lület létrehozásához új C/C---- kódot kell készíttetni vele. Ezt 
ismételgetni elég unalmas lehet, különösen akkor, ha a grafi- 
kus felületet előállító kódot módosítottuk. Éppen azért készí- 
tette el James Henstridge a libglade-et, amely lehetővé teszi, 
hogy a grafikus felületet előállító kódot ne kelljen bedrótozni 
az alkalmazásokba. James hozta létre a GTKAIGNOME Python 
kötéseket, azt a Python modult, amely a GTKAIGNOME C 
függvények elérhetőségét biztosítja. 
A libglade használatakor programunk nem tartalmazza 
a grafikus felületet létrehozó kódrészleteket. A libglade ehe- 
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lyett a program futásakor dolgozza fel az XML fájlt, és futá- 
si időben hozza létre a megadott felületet. Amikor tehát 

a Glade segítségével változtatunk valamit a grafikus felüle- 
ten, nem kell módosítanunk az azt létrehozó kódot is. 
Jómagam szeretek Pythont használni, hacsak nem olyan 
kódot kell írni, amiben sok a számítási művelet, vagy fontos 
a gyors futás. A Python magas szintű adatszerkezetei és ér- 
telmezőkörnyezete rendkívül gyors kódfejlesztést, karban- 
tartást és módosítást tesznek lehetővé. A Linuxvilág 2003. 
októberi számában már megjelent egy bevezető jellegű 
cikk a PUGTK-ról és a Glade-ről, amely a Gtk és a Glade 
használatában járatlanok számára kiváló segítség az első 
lépésekhez. 

Feleségem egy szemvizsgálattal és optikával foglalkozó vál- 
lalkozásnál dolgozik. Éppen nekik készítettem egy adatbá- 
Zis-kezelő és számlázó rendszert, amikor elhatároztam 

a GladeGen megírását. Mielőtt a feleségem odakerül volna, 
egy Microsoft Access alapú rendszert használtak, amit ki 
tudja, ki fejlesztett ki. Mivel az illető már kilépett a cégtől, 
új rendszert akartak bevezetni. A város más hasonló vállal- 
kozásaival is felvették a kapcsolatot, és érdeklődtek, hogy 
milyen programot érdemes használni. Kiderült, hogy az 
összes többi helyen drága, hibáktól hemzsegő programok- 
kal küszködnek. Végül sikerült meggyőznöm a tulajdonost, 
hogy a nyár folyamán, nagyjából egy új program áráért el 
tudnék készíteni egy egyedi rendszert, ami pontosan azt 
nyújtja, amire szükségük van. Az egyetlen kérésem az volt, 
hogy Linuxot használhassak. 

Így készült el egy Python/GTK alapú, az adatok tárolására 
PostgreSOL-t használó program, amely minden keresési és 
táblázatkezelő műveletet SOL-parancsok segítségével végez 
el. A Python kód a PostgreSOL adatbázis és a GTK felület kö- 
zötti kapcsolatot adja. A GTK és a PostgreSOL egyaránt C- 
ben készült, vagyis mindkettő gyors. A Python kód a korsze- 
rű processzorokon szerencsére szintén elég gyorsan fut ah- 
hoz, hogy a kettő közötti kapcsolatokat képes legyen kezelni. 
A PyGTK felület PostgreSOL adatbázissal kombinálva tetsző- 
leges adatbázis-kiszolgáló elérését lehetővé teszi. A grafikus 
kezelőfelület több számítógépen is futhat, míg az adatbázis- 
kiszolgáló közös. Az ügyfél/kiszolgáló felépítésnek köszönhe- 
tően a grafikus felület bárhol futtatható, a PostgreSOL kiszol- 
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gáló pedig interneten keresztül, SSH-val titkosított kapcsola- 
ton keresztül is elérhető. Az az előnye is megvan tehát ennek 
a megoldásnak, hogy távolról is bele tudok nyúlni a rend- 
szerbe, ha egy felhasználónak valamilyen kérése van. 

A program több mint negyvenféle ablakkal rendelkezik. 
Ezek többek közt a páciensek adatainak, a keretek és len- 
csék eladásainak, a kapcsolattartási adatoknak és a biztosí- 
tóktól érkező kifizetéseknek a bevitelét, illetve a keretkész- 
let követését teszik lehetővé. Úgy döntöttem, az ablakok 
létrehozására Glade-et használok, és mivel Pythonban akar- 
tam programozni, kellett írnom egy olyan programot, ami 
önműködővé teszi az ablakokhoz tartozó kód elkészítését. 
Az eredmény a GladeGen. 


A GladeGen használata 
Az általam írt kód önműködővé teszi a felületet összeállító 
Python kód elkészítését, megadja a visszahívó függvények 
kapcsolatait, biztosítja a kezelőelemek elérését és üres 
visszahívó függvényeket hoz létre a Glade XML fájl alapján. 
A program használatával egy grafikus felületű program lét- 
rehozása a következő lépésekből áll: 
1) a felület grafikus összeállítása a Glade segítségével 

és az XML fájl elmentése 
2) a GladeGen tuttatása a kód előállítása végett 
3) a visszahívók kódjának megírása. 


A GladeGen által létrehozott kód minden az alkalmazás fut- 
tatásához és a felület megjelenítéséhez szükséges kódrész- 
letet tartalmaz, illetve az üres visszahívó függvények is 
megtalálhatók benne. Lehetővé teszi, hogy a felületet 

a Glade használatával módosítsuk. Ha újra lefuttatjuk 

a GladeGent, újra létrehozza az alkalmazás kódját, amelybe 
az összes új visszahívó és kezelőelem bekerül, ám a meglé- 
vő kódot nem módosítja. 

A továbbiakban egy matematikai kvízprogram elkészítésé- 
vel fogom szemléltetni a GladeGen használatát. A teljes 
program a 65. CD Magazin/Glade könyvtárában található. 
A GladeGen a GTK 2.x kezelőelem-készlettel és a megfele- 
lő Glade-változattal használható, Red Hat rendszereken 
ennek glade-2 a neve. Aki a GTK kezelőelemeket már 
ismeri, az a Glade-ben is otthonosan fog mozogni. Ellen- 
kező esetben előbb ismerkedjünk meg a kezelőelemek 
tárolóosztályaival, de legalább a táblázatokkal és a víz- 
szintes/függőleges dobozokkal. 

A glade-2 segítségével először elkészítettem a felület első 
változatát. Az első elem egy Gtkwindow volt, amihez egy 
GtkvBoxot adtam hozzá. A függőleges dobozba két 
GtkFrame kezelőelem kerül, s mindkét keretbe egy-egy 
GtkTable-t illesztettem. A további kezelőelemeket a két táb- 
lázatba tettem. A feladványban szereplő műveleti jelek és 

a számjegyek számának kiválasztását GtkspinButton keze- 
lőelemekkel tettem lehetővé. 

GtkcheckButton kezelőelemeket használtam annak jelzésé- 
re, hogy milyen műveleti jeleket kell használni a feladvány- 
ban. A feladványokhoz, a válaszhoz és helyesen/hibásan 
megválaszolt feladványok megadásához GtkEntry kezelő- 
elemeket alkalmaztam. Használtam még GtkLabel és 
GtkButton elemeket is. 

A Glade fájlt mathflash. glade néven mentettem. A Glade 
nem kérdez rá, hogy akarjuk-e menteni a munkánkat, tehát 
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1. ábra Gomb visszahívójának megadása Glade alatt 


ne feledkezzünk meg erről, ha valamilyen módosítást vé- 
geztünk a felületen. A felületet és magát a Gladet mutatja 
az 1. ábra. Látható, hogy a reset button gomb, az 

on reset button clicked függvényt hívja meg ha rá- 
kattintunk. 

A Glade lehetővé teszi, hogy az egyes kezelőelemeknek ne- 
vet adjunk, illetve alapértelmezett neveket is előállít. A keze- 
lőelemeknek, például a gomboknak és az adatbeviteli me- 
zőknek igyekeztem olyan nevet adni, amely utal használatuk 
módjára. A Glade-ben azt is megadhatjuk, hogy a visszahívó 
függvényekhez milyen jelzéseket szeretnénk kapcsolni. Így 
határoztam meg azt is, hogy az on. reset. button-t kell meg- 
hívni, ha a felhasználó rákattint a reset button-ra. 

A következő lépésben a GladeGen segítségével, 

a GladeGen.py mathflash.glade MathFlash MathFlash pa- 
ranccsal létrehoztam az alkalmazás sablonkódját. A pa- 
rancssorban átadott értékek a Glade XML fájl neve, a létre- 
hozandó Python fájl/modul neve, valamint az ebben a fájl- 
ban/modulban létrehozandó osztály neve. Az így kapott 
MathFlash.py fájl tartalmát mutatja az 1. kódrészlet. 

A Gladewindow osztály MathFlash osztály alosztálya, amely 
a libglade segítségével gondoskodik a handlers (kezelők) 
változóban felsorolt visszahívók kapcsolatairól. Egyút- 

tal egy szótárat is létrehoz self.widgets névvel, amely 
awidget list változóban szereplő kezelőelem-neveket 

a megfelelő Gtkwidget példányokhoz rendeli. 

A Gladewindow alosztály alapértelmezett show (megjelenítő) 
és hide (elrejtő) eljárásokat is biztosít, így a sablonkód 
azonnal futtatható, és a felület a visszahívók megírásának 
megkezdése előtt ellenőrizhető. 

A GladeGenConfig.py fájl lehetővé tesz bizonyos testre- 
szabásokat, például a program készítőjének megadását, 

a self .widgets szótárba illesztendő elemtípusok kiválasz- 
tását és a létrehozandó Python kód kinézetének meghatáro- 
zását. A megadott GladeGenConfig.py fájlban a Gtkwindow, 
GtkButton, GtkSpinButton, GtkcheckButton, GtkEntry, 
Gtkcombo és a GtkTextview elemtípusok szerepelnek. 

A GtkLabel elem és a befoglaló elemek elérésére ritkán 

van szükség, ezért nem szerepelnek a GladeGenconfig 
include widget. types listájában. 

A létrejött MathFlash.py fájl az összes visszahívó függvényt 
tartalmazza, ezek törzse azonban egyelőre a Pythonban az 
üres műveletet jelző pass utasításból áll. Az eljárások meg- 
adása a self átadott értékkel, illetve a tetszőleges hosszúsá- 
gú átadott értéklista kezelésére alkalmas "args mutatóval 





1. kódrészlet A GladeGen ezt a Python kódot állította elő 
a Glade által készített XML fájl alapján 


$1!/usr/bin/env python 
$————————————————————— 
ff MathFlash.py 

ff Dave Reed 

ft 02/28/2004 


import sys 
from Gladewindow import " 


ESZ ESEL ES zenesz es 


class MathFlash(Gladewindow) : 


def — int. (selH: 


self.initO 


def init(self): 

filename - "mathflash.glader 

widget list — [ 
"window1" , 
"plus check , 
"minus check  , 
"multiply check  , 
"divide check", 
fdügyeséspíin 
"operators spin , 
"correct entry , 
"wrong. entry , 
ÍDGEZeNtry 
"problem entry" , 
"answer. entry , 
"submit button , 
"reset button , 


történik. Python alatt a "args segítségével egy függvény- 
nek/eljárásnak tetszőleges számú értéket lehet átadni, a hí- 
vó függvény ezeket tuple formájában kapja meg. A vissza- 
hívók jelentős hányada egyrészt az esemény által érintett 
kezelőelem azonosítóját, másrészt az esemény egyéb jel- 
lemzőit kapja meg, ha vannak ilyenek. A GTK weboldalon 
elérhető API leírásban minden visszahívó átadott értékei 
megtalálhatók. 

Következő teendőnk a visszahívók kódjának megírása és 

a programhoz szükséges egyéb kódok elkészítése. Ennél 

a programnál nagyjából még 60 sornyi Python kóddal teljessé 
tehető a MathFlash.py fájl. Egy tapasztalt Glade-használó és 
Python-programozó nulláról indulva nagyjából fél óra alatt 
össze tudja állítani a teljes kódot. Az összetettebb programok 
írásakor a modelllnézet/vezérlés tervezési sorrendet érdemes 
követni. A GladeGen által előállított kód maga a vezérlés. 

Az on submit button clicked visszahívó példáján vizsgál- 
juk meg, hogyan kell használni a GladeGen által előállított 
PyGTK kódot. Az általam írt Python kód a következő: 

def on submit button clicked(self, "args): 
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"exit button , 
"new button , 
"result entry, 
] 
handlers — [ 
"on operator check toggled , 
"on submit button clicked , 
"on reset button clicked , 
"on exit button clicked , 
"on new button clicked , 
1 
top. window -— "windowl! 
Gladewindow. init (self, filename, 
top. window, widget list, handlers) 


ESZA TESB E SE ENES EB 
def on operator check toggled(self, "args): 
pass 
def on submit button clicked(self, "args): 
pass 
def on reset button clicked(self, "args): 
pass 
def on exit button clicked(self, "args): 
pass 
def on new button clicked(self, "args): 
pass 
EE SZETESETT EE 
def main(argv): 
w - MathFlashO 
w.showO 
gtk.mainO 
JESSE ee eszét 
17 nee A Md E 


main(sys.argv) 


prob - 

s self.widgets[/ problem entry" ].get textO 
ans - eval(prob) 

user - 
int(Cself.widgets[/answer entry"].get textO) 

self.total 4— 1 

if ans —— user: 

self.correct 4— 1 


self.widgets[/ result entry/].set text( Helyes ) 
else: 
self.widgets[ result entryí].set text( 
"Hibás, a helyes válasz: Xd" X ans) 
self.show resultsO 


A C GIK API tartalmazza a G CONST. RETURN gchar" 

gtk entry get text(GtkEntry "entry) függvényt. Mivel 

a Python objektumközpontú nyelv, a kötéseket az osztályhoz 
tartozó eljárásokként adhatjuk meg. Python kötéseknél 
agtk ésawidget előtagok kimaradnak a függvénynevek- 
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2. ábra Math Flash 


ből, és az adott kezelőelem Python példányával kerülnek 
meghívásra. Ugyanez érvényes az összes GTK függvényre is. 
A self .widgets példány használatával a megfelelő Python 
hívás self.widgets[/ problem entry] .get. textO formát 
ölt, ahol a problem entry a Glade XML fájlban szereplő bevi- 
teli kezelőelem neve. 

Ezután a Python eval függvényével végzem el a feladvány- 
ra adott válasz kiértékelését. Ez sokkal egyszerűbb, mint sa- 
ját értelmezőt írni a kifejezés kezelésére. Általános szabály, 
hogy a szorzás és az osztás elsőbbséget élvez a kivonással 
és az összeadással szemben. Az eval függvény használata 
biztonsági szempontból aggályos lehet, ha a kiértékelt ka- 
rakterlánc megadását a felhasználóra bízzuk. Ebben az eset- 
ben azonban ezt saját programunk állítja elő, így ezzel kér- 
déssel nem kell foglalkoznunk. 

Ha módosítjuk a Glade XML fájlt, futtassuk újra 

a GladeGent, amely elvégzi az új visszahívó eljárások 
hozzáadását. Eközben az általunk már megírt kódot nem 
változtatja meg és nem írja felül. Ez alól az init metódus 
az egyetlen kivétel, amit soha ne módosítsunk, mert 

a GladeGen minden futtatásakor újat készít belőle. Az init 
tartalmazza a kezelőelemek és a visszahívók nevét, vagyis 
muszáj a Glade fájl minden frissítésekor újra előállítani. Én 
például utólag adtam hozzá a statisztika nullázására szolgá- 
ló gombot. Amikor újra futtattam a GladeGent, akkor hoz- 
záadta az üres on reset button clicked eljárást, illetve 
készített egy új init eljárást, amely a reset. button kezelő- 
elemet és az on reset button clicked visszahívót is tar- 
talmazta. Mivel a kezelőfelület létrehozása futási időben, 

a libglade segítségével történik, további módosításokra 

nem volt szükség. 


Hogyan működik a GladeGen? 

A GladeGen először megvizsgálja, hogy a megadott mo- 
dul/fájl létezik-e. Ha nem, létrehoz egy alapszintű fájlt, 
amelyben a szerző neve és egy osztály szerepel. Ezután fel- 
dolgozza a Glade XML fájlt, és összeállítja ak kezelőelemek 
és az eseménykezelők listáját. A Python az inspect modul- 
lal teszi lehetővé, hogy egy program meghatározza, egy 
meglévő Python modul milyen függvényeket, osztályokat 
és eljárásokat tartalmaz, valamint ezekhez mely sorok tar- 
toznak. A GladeGen is ezzel vizsgálja meg, hogy mely 
visszahívókat írtunk már meg, és ezeket nem cseréli le 

üres visszahívó eljárásra. A program az új visszahívókat 

az osztályok meghatározásának aljára illeszti. Az inspect 
segítségével a GladeGen azt is meg tudja állapítani, hogy 
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mely sorok tartalmazzák az init eljárást, majd képes 

új, a legújabb Glade XML fájlban szereplő kezelőelemek 

és eseménykezelők mindegyikét tartalmazó init eljárás- 
ra cserélni. 

A Python az XML fájlok feldolgozására szabványos DOM 
és SAX felületen keresztül egyaránt képes. A SAX egy ese- 
ményvezérelt modell, amelyben a felhasználó adja meg az 
XML-címkék feldolgozásakor meghívandó függvényeket. 
A DOM felület a teljes XML fájlt beolvassa a memóriába, 
majd megfelelő függvényeket biztosít az XML-szerkezet 
bejárására és az adatok kinyerésére. A GladeGen esetében 
csak az XML fájlban szereplő adatokra van szükségünk, így 
a DOM felületet egyszerűbb használni. A Glade XML fájlok 
elég kis méretűek, így minden probléma nélkül betölthetők 
a memóriába, és Python-téle megjelenítésük létrehozásával 
sem kötünk le túl sok memóriát. A DOM felület használatá- 
val a GladeGen get. xm! eljárása körülbelül 30 sornyi 
Python kóddal hámozza ki a kezelőelemek és az esemény- 
kezelők nevét a Glade XML fájlból. 


Osszegzés 

A Glade és a GladeGen segítségével gyakorlatilag önmű- 
ködően oldható meg a grafikus alkalmazások kezelőele- 
meinek létrehozása. Így megszabadulunk az ezekkel kap- 
csolatos kód és a visszahívó függvények megírásának 
unalmas és sokat ismételt feladatától. A két programmal 
jelentősen felgyorsítható a Python/GNOMEI/GTK alapú 
alkalmazások fejlesztése. A példaként elkészített Math 
Flash a 2. ábrán látható. A GladeGen program minden 

a Python-t és a GTK-t támogató operációs rendszeren, 
vagyis Linuxon, UNIX-on, Mac OS X-en és Microsoft 
Windowson egyaránt futtatható. 

A rendszer számos további szolgáltatással bővíthető. 

A létrejövő visszahívó függvények általános "args pa- 
ramétere helyett az átadott értékeket nyíltan, a kezelő- 
elemek és a visszahívó prototípusa alapján is meg lehet- 
ne adni. A programot egy a GladeGenConfig.py fájlban 
szereplő beállítások módosítására használható grafikus 
felülettel is tervezem bővíteni. A GladeGen program 
GPL hatálya alatt jelenik meg. Ha bárki érdeklődne 

a módosítása vagy bővítése iránt, vegye fel a kapcsola- 
tot a szerzővel. 


Köszönetnyilvánítás 

Köszönettel tartozom hallgatóim egyikének, Jeremiah 
Schilensnek, aki a program egy korábbi változatán dolgo- 
zott együtt velem. 


Linux Journal 2004. július, 123. szám 





Hm.  ] David Reed az Ohio államban található 

A! Columbus városában él feleségével és két 
kutyájával. 1991 óta dolgozik unixos, 

1997 óta pedig linuxos rendszerekkel. 
Doktori dolgozatát a grafikai térfogatelem- 
zésről írta az Ohio State Universityn. 
Jelenleg informatikát tanít a Capital 
Universityn, ahol az informatikai tananyag- 
nak a Python, a C4-- és a Java is része. 
David a dreed€ocapital.edu címen érhető el. 











Adatgyújtés a Comedi segítségével 


Létezik egy szabványos alaprendszer, amely számos különböző adatgyűjtő kár- 
tyához egységes API-t biztosít. Aki akarja, akár egy normál számítógép párhuza- 


mos kapuján keresztül is kipróbálhatja. 


legtöbb kutató és mérnök imádja az adatokat. 
A Minél több adatot kapnak, annál szélesebb mosoly 

ömlik szét az arcukon. Ezeknek az embereknek 
a mérés a mindene. A folyamatok felismeréséhez, a rendel- 
lenes jelenségek felfedezéséhez és a végső következtetések 
levonásához a laborokban dolgozóknak ügyelniük kell arra, 
hogy teljes adathalmazokat gyűjtsenek. 
Az adatgyűjtés fogalma számos ötletet és fogalmat ölel fel. 
A legtöbb kutató és mérnök ugyanakkor egyetért abban, 
hogy az adatgyűjtés valamilyen természetes folyamat jellem- 
zőinek mérését jelenti. Lehet szó egyszerű hőmérsékletmérés- 
ről, vagy akár olvadt acél szennyeződéseinek vizsgálatáról. 
A számítógépek világában az adatgyűjtés általában valami- 
lyen feszültség mérésével történik. Ilyenkor rendelkeznünk 
kell valamilyen érzékelővel vagy műszerrel, amely a számí- 
tógép számára mérhető feszültségeket állít elő. Fontos per- 
sze az is, hogy ismerjük a mért jellemző és az érzékelő fe- 
szültségkimenete közötti összefüggést. Jó esetben a kapcso- 
lat lineáris. Ilyen például az, ha egy foknyi hőmérsékletkü- 
lönbséghez mindig 0,1 voltos feszültségeltérés tartozik. 
A korszerű alaplapokon beépített érzékelők találhatók, ame- 
lyek képesek a teljes rendszer állapotáról képet alkotni. Ilyen 
eszköz például a National Semiconductor LM78 jelű terméke. 
Ezek az érzékelők a gyakorlatban általában a hűtőventiláto- 
rok fordulatszámát, a processzormag feszültségét és hőmér- 
sékletét, illetve a merevlemezek fordulatszámát mérik. Az 
adatokat maga a lapka gyűjti össze, a processzorhoz pedig 
egy soros buszon keresztül juttat el őket. A nyílt forrású 
Im sensors projekt (5 secure.netroedge.com/-—1lm78) program- 
ja az alaplapok működésének figyelését számos szempont 
szerint teszi lehetővé. 
A normál személyi számítógépek ettől függetlenül nem 
rendelkeznek általános, analóg adatok begyűjtésére alkal- 
mas csatolófelülettel. Így ha külső feszültségeket akarunk 
mérni velük, akkor új felületre van szükségünk. Pontosan 
ilyen célra tervezik a PCI és ISA buszos kivitelben egyaránt 
létező adatgyűjtő (data acguisition, DAO) kártyákat, ame- 
lyek számos gyártó termékkatalógusaiban megtalálhatók. 


A Comedi projekt 


A legtöbb Linux-felhasználó alighanem jól tudja, miféle 
gondokkal jár akár csak egy-egy nyomtató kapcsán a gyár- 
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tók, a márkák, a típusok és az illesztőprogramok követése. 
Általános jelenség, hogy bármilyen szabványosítási törek- 
vés csakhamar hatalmas fejlesztési projektté növi ki magát. 
Ha a tervezet kellő támogatást kap, akkor szabvány szüle- 
tik belőle. Vannak gyártók - ilyen például a National 
Instruments — amelyek eleve adtak ki linuxos illesztőprogra- 
mokat adatgyűjtő eszközeikhez, és vannak, amelyek nem. 
A Comedi, vagyis a Control and Measurement Device 
Interface (vezérlő- és mérőeszköz felület) a linuxos adat- 
gyűjtő illesztőprogramok és könyvtárak szabványos készle- 
te. Fejlesztését 1996-ban David Schleef, kezdte meg. 

A Comedi célja több kártyagyártó és -modell támogatása 
egyetlen közös felületen keresztül. Az API tervezésekor 
lényegében a modularitás és a bonyolultság között kellett 
egyensúlyt teremteni. A többi linuxos illesztőprogram fej- 
lesztéséhez hasonlóan a munka egy részéhez rengeteget 
kell bújni a különféle eszközök leírásait, más részéhez 
visszafejtéseket kell végezni, bár természetesen a gyártók 
által a Comedi fejlesztéséhez a saját termékükre kiterjedően 
nyújtott támogatást sem szabad elfeledni. 


Hogyan működik? 

A Comedi két részből áll. Maga a Comedi illesztőprogramok 
gyűjteménye, amelyeket a rendszermag térbe kell betölteni, 
a comedilib pedig ezekhez az illesztőprogramokhoz nyújt 
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2. ábra A normál és a valós idejű linuxos folyamatütemezés 
összehasonlítása 


hozzáférést a felhasználói térből. A Comedi átlátszósága 

a comedilib szolgáltatásainak köszönhető. Comedire épülő 
programokat C vagy C-t nyelven lehet írni, ezen kívül 
Perl és Python kötések is léteznek hozzá. 

A Comedi mindent csatornákra, aleszközökre és eszközökre 
oszt fel. A csatorna a legalacsonyabb mérési vagy vezérlési 
szint. Több azonos típusú csatorna együtt egy aleszközt al- 
kot, a teljes eszköz pedig ilyen aleszközökből áll össze. 

A Comedi használatakor először egy Comedi illesztőprog- 
ram töltődik be a memóriába. Ezután a /usr/sbin/ 

comedi config fut le, amely létrehozza az illesztőprogram 
kötését a megfelelő Comedi eszközhöz, ez lehet például 

a /dev/comedi0. Végül a DAO-kártya által biztosított szolgál- 
tatásokat a comedilib függvényei révén lehet elérni. 


Laboratóriumi példa 

DAC és a Comedi együttes használatára többek közt az 
Analytical Engineering, Inc. (AED) aerodinamikai laboratóri- 
umában láthatunk példát. Itt egy ventilátor légáramát 
különféle méretű nyílásokon vezetik keresztül, a techniku- 
sok pedig egy egyedi program segítségével követni tudják 
a nyílásokban létrejövő nyomás alakulását. A mérés alapján 
ki lehet számítani a nyílásokon átáramló légtömeg nagysá- 
gát. Ezek a mérések és számítások alapvető jelentőséggel 
bírnak, mivel a technikusok ezek alapján tudják ellenőrizni, 
hogy a különféle műszerek kalibrálása helyes-e. 
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1. kódrészlet Példaprogram feszültségszint 
lekérdezésére az 1-es csatornáról 


finclude cstdio.hz 
$finclude ccomedilib.h: 


const char "filename - "/dev/comediO"; 
int mainCint argc, char "argv[]) 
í 

lsampl t data; 

int ret; 


comedi t "device; 
/:" A kártya melyik eszközét akarjuk 
használni? "/ 
int subdevice — 0; 
/" A csatorna kiválasztása "/ 
int channel SO 
/:" Az elérhető tartományok egyikének 
kiválasztása "/ 
int range z 0; 
/" Mérések végzése földhivatkozással "7/ 
int analogref - AREF GROUND; 
device - comedi open(filename); 
if(!device) ( 
/" Nem tudtuk megnyitni az eszközt - hiba 
történt 7 
comedi perror(filename) ; 
exit(0); 
3 
/: Adat beolvasása "/ 
ret-comedi data read(device, subdevice, 
channel , range , analogref , edata) ; 
if(retc0)( 
/" valamilyen hiba történt "/ 
comedi perror(filename) ; 
exit(0); 
3 
printf("A következő adatot kaptuk: 
data); 
return 0; 
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A tényleges tömegáramlást még nehezebb pontosan kiszámí- 
tani. Meghatározásához kétféle légnyomást, három légáram 
hőmérsékletet, a nedvességtartalmat, a légköri nyomást és 

a magasságot kell ismerni. Mindezeket a mennyiségeket hét- 
köznapi kereskedelemben kapható eszközökkel is át lehet 
alakítani feszültségekké. Az egyik legnépszerűbb csatolófelü- 
let az 5B. Ilyen típusú moduláris blokkokat használva mind- 
ezeket a mennyiségeket a DAO kártya által olvasható feszült- 
ségekké lehet formálni. A Comedi segítségével mindezeket 

a feszültségeket könnyedén, a comedi data read függvény 
meghívásával tudjuk beolvasni. Ez a kiválasztott csatornát 
figyelve egyszerűen egy értéket ad vissza, amely lehet pél- 
dául 3421. De vajon mit jelent ez a szám? 

A DAO kártyák meghatározott felbontással dolgoznak. 

A leggyakoribb a 12 bites pontosság. Mindegyikhez egy 
adott feszültségtartományban dolgozik, amelyre a mérési 
eredményeket leképezi. Mivel 12 biten a 0-4095 értéktarto- 














3. kép Motor vizsgálat közben 


mány ábrázolható, könnyen kiszámíthatjuk, hogy a 3421 
jelentése: 3421/4095 "(a teljes mérési tartomány). Ha példá- 
ul eszközünk a [0, 5] feszültségtartományban dolgozik, 
akkor a 3421 értéknek 4177 voltos feszültség felel meg. 
Mindezen adatok birtokában, illetve tudva, hogy az 5B blokk 
a [0 volt, 5 volt] feszültségtartományra a [0 "C — 100 7C] hő- 
mérséklettartományt képezi le, néhány pillanat alatt ki tud- 
juk számítani, hogy a fenti feszültség 83,56 "C-os hőmérsék- 
letet jelez. Gyúrjuk össze a szükséges méréseket, csapjunk 
hozzá egy csinos grafikus felületet, és ismételjük meg a mé- 
rést minden másodpercben. 

Természetesen ennél bonyolultabb adatgyűjtéseket is vé- 
gezhetünk. Az adatok begyűjtésekor fontos szempont a se- 
besség. Elég gyorsnak kell lennünk ahhoz, hogy a minták 
között semmilyen fontos adatot ne hagyjunk figyelmen kí- 
vül. Ennek elérésére a Comedi egy parancsfelületet is bizto- 
sít, amellyel szinkronizált mintavételt lehet végezni. 

A DAO-kártya képességeitől függően az időzítésről prog- 
ram alapú és a kártya által biztosított megszakítások egy- 
aránt gondoskodhatnak. 

A Comedi a legtöbb adatgyűjtési feladatot kiválóan ké- 
pes ellátni. Lényegében a Comedi szolgáltatásait csak 

a futtatására használt hardver képességei korlátozzák. 

Az olcsóbb kártyák általában kisebb mintavételi gyakori- 
sággal dolgoznak. Ha gyorsabb adatgyűjtést akarunk 
végezni, akkor drágább kártyát kell választanunk. Ezek 
DMA-kezelésre is képesek, az adatgyűjtést pedig saját 
processzoruk vezérli. A Comedi ilyenkor csak a pufferelt 
adatok továbbítását irányítja. 

A gyors beolvasás ugyanakkor nem jelent egyben gyors fel- 
dolgozást is. A közönséges Linux rendszermag viselkedése 
mellett valós idejű feldolgozást is végezni gyakorlatilag lehe- 
tetlen. Ehhez a folyamatok ütemezését szigorú szabályok 
alapján kellene végezni. Természetesen erre is van megoldás. 
A Linux Real-Time Application Interface (RTAI, valósidejű 
alkalmazásfelület) és az RTLinux csupán két példa a számos 
lehetőség közül, amelyekkel feljavítható a rendszermag 
időzítésvezérlése. Mindkét csomaghoz létezik Cornedi felület. 
A valós idejű felületek mögötti alapötlet roppant egyszerű. 
A rendszermagot nem monolitikus folyamatként kell futtat- 
ni, hanem egy kis méretű és hatékony ütemező gyermekfo- 
lyamataként. Így a rendszermag nem tudja blokkolni a meg- 
szakításokat, illetve szükség esetén el lehet venni tőle az erő- 
forrásokat. Ezután bármely a rendszer felett valós idejű ve- 
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4. ábra A motorok vezérlése és jellemzőinek Comedi 
segítségével végzett mérése 


zérlési lehetőséget igénylő alkalmazás bejegyezheti magát 
az ütemezőnél, és olyan gyakran foszthatja meg a rendszer- 
magot az erőforrásoktól, amilyen gyakran csak szeretné. 


Vissza a laboratóriumi példához 

Az AEI több tesztkamrát is fenntart dízelmotorok tesztelé- 
séhez. Minden cellában egy motor található, számos hőmér- 
séklet- és nyomásmérő műszerrel felszerelve. Be szoktak 
építeni egy frekvenciamérőt is, amely a motor fordulatszá- 
mát figyeli. Végül a motort egy erőmérőhöz csatlakoztatják, 
amely valós vezetési helyzeteket szimulál úgy, hogy változó 
ellenállást fejt ki a működő motorral szemben. A létrejövő 
nyomatékot szintén mérjük. 

A motoradatok beolvasási sebessége viszonylag kicsi, má- 
sodpercenként mindössze 20 mintát veszünk. Ha az adatok 
begyűjtése volna az egyetlen feladat, akkor az egész rend- 
szer meglehetősen egyszerű lenne. Csakhogy az újabb 
adatkészletek beolvasásakor különféle beállításokat kell 
finomhangolni és szabályozni. A motor sebességét adott ér- 
téken kell tartani, ehhez változtatni kell a fojtószelep állását, 
illetve az erőmérő által adott terhelést. A cellának a hűtőfo- 
lyadék áramlását szabályozó szelepeit ugyancsak folyama- 
tosan állítani kell, mert a hűtőfolyadék hőmérsékletét állan- 
dó értéken kell tartani. Biztonsági méréseket ugyancsak kell 
végezni, ezekkel ellenőrizhető, hogy katasztrófához vezető 
körülmények nem alakultak-e ki. 

Ráadásul minden ellenőrzést és az új értékek beállítását 
még az előtt kell elvégezni, hogy egyéb teendői elvégzésére 
a rendszermag átvenné a vezérlést. Ha a Linux rendszer- 
mag maga gondoskodna erről az ütemezésről, nagy valószí- 
nűséggel minden megfelelően működne. Sajnos azonban 
nem lehet előre megmondari, hogy a teljes folyamat egyes 
lépései mikor kerülnek végrehajtásra. Az említett valós ide- 
jű kiterjesztések használatával ugyanakkor ez a probléma 
automatikusan megoldódik. 

A valós idejű rendszermagoknak hátrányaik is vannak. 
Amikor a valós idejű ütemező meghatározott időszeletben 
futtat egy folyamatot, a Linux rendszermag futása lényegé- 
ben megakad. A valós idejű folyamatnak ezért gyorsnak és 
hatékonynak kell lennie, és a lehető leghamarabb vissza kell 
adnia a vezérlést a rendszermagnak. Ha ezt elmulasztja, ak- 
kor a rendszer egyéb, nem valós idejű részei eléggé akadoz- 
va fognak futni. Ha pedig a valós idejű folyamatban valami 
hiba történik, és a rendszermag soha nem kapja vissza a ve- 
zérlést, akkor a teljes rendszer összeomolhat. 
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5. kép Csatoló áramkör a lámpák párhuzamos kapuról 
végzett vezérléséhez 


Gyakorlati példa 

A laboratóriumok mellett a Coredi akár otthon is használ- 
ható. Egy egyszerűbb adatgyűjtő kártyához már 20-60 ezer 
forint körüli áron hozzájuthatunk, a gyártó nevétől, a kár- 
tya bonyolultságától és mintavételi gyakoriságtól függően. 
Egy ilyen eszközzel lakásunk különféle pontjain mérhetjük 
a hőmérsékletet, vagy mágneses érzékelővel figyelhetjük, 
hogy nem felejtettük-e nyitva a garázsajtót. 

A személyi számítógépek érdekes jellegzetessége, hogy 

a párhuzamos kapuk vonalait külön is lehet vezérelni. 

A Comedi segítségével ezeket a vonalakat roppant egyszerű- 
en tudjuk be- és kikapcsolni. Megfelelő relével párosítva pe- 
dig ezekkel gyakorlatilag bármit ki-be tudunk kapcsolgatni. 
Bár a párhuzamos kapuk az említett 0-5 voltos feszültség- 
szintekkel dolgoznak, kellő áramerősséget nem képesek le- 
adni. Párhuzamos kaput tehát nem szabad közvetlenül 

a vezérelni kívánt készülékhez csatlakoztatni, mindig vala- 
milyen köztes áramkört kell beiktatni. Ilyen áramkörök ké- 
szítéséhez számos weboldalon találhatunk leírásokat. 

Én egy öreg 486-oson futtatom a Comedit, és két párhuza- 
mos kapu segítségével hozom létre az évi nyaralásunkkor 
szokásos fényjátékot. A házban a lámpák a szokásos módon 
vannak felszerelve, de mindegyikhez külön érpár vezet, 
amelyek a vezérlőszobában futnak össze (esetemben ez egy 
üresen álló hálószoba). Az érpárok egyedi áramköri laphoz 
csatlakoznak. Ezen találhatók azok a mechanikus relék, 
amelyek áramot adnak a lámpáknak, ha 5 voltos jelet kap- 
nak a párhuzamos kapuról. Egy egyszerű C programot 
használok, amely Comedi függvényhívásokkal egyenként 
vezérli a párhuzamos kapu vonalait, vagyis be- és kikap- 
csolja a világítótesteket. Azt, hogy az egyes lámpákat mikor 
kell be- és kikapcsolni, egy egyszerű szöveges fájlban tu- 
dom megadni. A szomszédom nagy örömére... 


Osszefoglalás 

Az adatgyűjtés lehetősége a laboratóriumokban rendkívül 
értékes. A Comedi által biztosított általános felülettel a Linux 
a legkülönfélébb DAO-kártyákkal is kiválóan használható. 
Ahogy a Linux egyre népszerűbbé válik, úgy a Comedihez 
hasonló felületek fontossága is növekedni fog. 

Az egyszerű DAO-kártyák lassanként megfizethetővé vál- 
nak, a Linux alapú adatgyűjtés pedig valószínűleg egyre in- 
kább elnyeri majd a területtel csak hobbiként vagy barkácso- 
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2. kódrészlet Parancsok és ravaszok segítségével 
végzett, az előbbinél bonyolultabb pásztázást 
szemléltető kód 


/" cél: A Comedi beállítása kétcsatornás adat- 
gyűjtésre és mindkét adatkészlet kétszeri beol- 
vasása. Az adatgyűjtést egy digitális vonalon 
érkező ravaszjel hatására indítjuk el. 
87 
comedi cmd c, "cmd-€c; 
unsigned int chanlist[21; 
/" A CR PACK egy különleges Comedi makró, 
amely a csatorna, a tartomány és 
a földhivatkozás beállítására szolgál. 


€7 
ehanikuse LON ERÉPRÁGK(OSOSOJTS 
ehanil vst d SZ EREPAGKCÉTOT 00 


/" Melyik aleszközt kell használnunk? "/ 
/:" A legtöbb kártyán a nullás aleszköz egy 
analóg bemenet. "/ 


cmd-s:subdev SSül0 S 
cmd-schanlist z"sehanlnsts 
cmd-schanlist len - n chan; 


/"A parancs elindítása a külső digitális vo- 
nalon érkező jelzés hatására. A start arg ál- 
tal megadott digitális csatornát használjuk. 


17 


cmd-sstart src - TRIG EXT; 
cmd-sstart arg — 3; 
/" A ravaszjel után azonnal megkezdjük a pász 


tázást. "/ 
cmd-sscan begin src 
cmd-:sscan begin arg 
/" A pásztázás után 
átalakítást. "/ 
cmd-sconvert src - TRIG NOW; 
/" A scan end arg csatorna lekérdezése után 
befejezzük a pásztázást. 
57 
cmd-:sscan end src 
cmd-sscan end arg 
/" stop arg számú 
leállítjuk. "/ 
cmd-sstop src - TRIG COUNT; 
cmd-sstop. arg - 2 
/" A parancs indítása "/ 
comedi cmd(device, cmd); 


TRIG FOLLOW; 
0; 
azonnal elvégezzük az 


TRIG COUNT; 
2; 
pásztázás után a parancsot 


lási céllal foglalkozók tetszését. Ami korábban költséges hard- 
ver és programok vásárlását igényelte, az ma már - a legkü- 
lönfélébb területeken — bárki számára hozzáférhető. 


Linux Journal 2004. augusztus, 124. szám 


Caleb Tennis 1996 óta használ Linuxot. Ő volt a KDevelop 
Project egyik vezetője, jelenleg elsősorban a KDE Gentoo 
alatti változatának karbantartásával foglalkozik. Egy dízelmo- 
tor-tesztlabor mérnöki munkáit felügyeli, s eközben részidő- 
ben egy helyi főiskolán linuxos témákban oktat. 
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Fájlrendszer-címkézés a SELinuxban 


A SELinux sokkal kifinomultabban vezéreli a fájlokhoz való hozzáférést. Lássuk! 


ost, hogy az NSA Security Enhanced Linux (Foko- 
JA zott Biztonságú Linux) része lett a 2.6-os rend- 

szermagnak, és így eljut a különböző Linux ter- 
jesztésekbe, valószínűleg egyre többen telepítik majd a 
SELinuxot, és kezdenek kísérletezni vele. Ezeknek a jövőbe- 
ni felhasználóknak kíván segítséget nyújtani ez a cikk, kö- 
zelebbről is megvizsgálja a SELinux alatti fájlrendszer-cím- 
kézést. Bár ez az írás alapvetően a középhaladóknak szól, 
a következő bekezdésben rövid áttekintést adok a SELinux 
néhány alapelvéről, a hálózaton található forrásokban pe- 
dig szerepel néhány hivatkozás a részletesebb információk 
forrásaira. Faye Coker bemutató cikke (Linux Journal, 2003. 
augusztus) különösen ajánlott azoknak, akik csak most kez- 
denek ismerkedni ezzel a különleges területtel. 


SELinux áttekintés: címkézés és hozzáférés-szabályozás 
A SELinuxban valamennyi, biztonsági szempontból fontos 
objektumhoz, például a feladatokhoz, a fájlleírókhoz és ma- 
gukhoz a fájlokhoz egy-egy biztonsági környezet tartozik, 
vagyis egy-egy olyan címke, amely magában foglalja az 
adott objektumhoz kapcsolódó biztonsági jellemzőket. 

A szabványos SELinuxban ez egy kettősponttal elválasztott 
karakterlánc, amely azonosító, szerep és típus értékekből áll. 
Ezeket a címkéket egy biztonsági kiszolgáló nevű rendszer- 
mag-összetevő rendeli hozzá a megfelelő objektumokhoz, 
mégpedig a biztonsági házirend adatbázisában megadott 
szabályok alapján. A szerző munkaállomásán található 
/etc/shadow fájl biztonsági környezeti címkéje például 

a következő: 


system u:object r:shadow t 


A system u és az object r a fájlokban használt általános 
azonosító és szerep értékek, míg a shadow t a fájl típusa. 
Ez utóbbi egy olyan jellemző, amely meghatározza, hogyan 
lehet elérni az adott fájlt. Egy folyamatot a következőkép- 
pen lehet címkézni: 


root:staff r:staff t 


A SELinux azonosító itt root, amelyet a SELinux a szabvá- 
nyos LINIX azonosítónál tartósabb azonosítófajtaként ren- 
del hozzá. A szerep itt staff. r, ami azt jelöli, hogy a folya- 
mat az ehhez a szerephez rendelt összes jogosultsággal 
rendelkezik. A folyamathoz kapcsolt típus a staff. t. A fo- 
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lyamatoknál a típus jellemző meghatározza, hogy azok ho- 
gyan férhetnek hozzá az objektumokhoz, és hogyan léphet- 
nek kapcsolatba más objektumokkal. A folyamatok típus 
jellemzőjét gyakran tartományként is emlegetik. 


Hozzáférés-szabályozási döntések 

A SELinux a biztonsági környezeti címkék segítségével 

a folyamatok és az objektumok közötti kapcsolatrendszert 
határozza meg. A rendszer működése közben folyamato- 
san döntéseket hoz azzal kapcsolatban, hogy melyik folya- 
mat melyik objektumhoz férhet hozzá, és pontosan ho- 
gyan. De hogyan történik a gyakorlatban mindez? 

A SELinux ,kapaszkodókat" (hooks) helyez el az alapvető 
rendszermagkód stratégiai pontjain, például ott, ahol a fel- 
használó éppen olvasni kezdi a fájlt. Ezek a kapaszkodók 
lehetővé teszik a SELinux számára, hogy felfüggessze 

a rendszermag rendes adatforgalmát, és kifinomult dönté- 
seket kényszeríthessen ki a hozzáférések szabályozása te- 
rén a megfelelő kérésekkel. A hozzáférés-szabályozási dön- 
tések általában folyamatok (például cat) és objektumok 
(például /etc/shadow) között történnek, meghatározott 
jogosultságok megszerzése végett. (Példánknál maradva 

a cat-nek nyilván olvasási jogosultságot kellene szereznie 
az adott fájlra.). A döntéskérések a hozzáférés vektortárba 
(Access Vector Cache — AVC) kerülnek, amely átadja a kéré- 
seket a biztonsági kiszolgálónak, kiértékelésre. A biztonsági 
kiszolgáló a kapott adatokat egyezteti a biztonsági házi- 
rend adatbázis tartalmával, majd meghatároz egy ered- 
ményt, amely az AVC-ben tárolódik, és visszatér a megfele- 
lő SELinux kapaszkodóhoz. A SELinux kapaszkodó ezután 
vagy engedélyezi a forgalom folytatását, vagy egy EACCES 
értéket ad vissza, a döntés eredményétől függően. A folya- 
matokhoz és az objektumokhoz rendelt biztonsági környe- 
zeti címkék ezeknek a döntéseknek a meghozatalát támo- 
gatják. Az 1. ábrán ennek a folyamatnak egy egyszerűsített 
változatát láthatjuk. 

A következő kód azt szemlélteti, hogy a biztonsági környe- 
zeti címkék hogyan működnek egy valódi rendszeren, illet- 
ve mit lát maga a felhasználó az egész folyamatból: 


$ id -Z 
root:staff r:staff t 


$ cat /etc/shadow 


cat: /etc/shadow: Permission denied 
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Az ellenőrzési napló a következőt rögzíti: 

avc: denied ( read ; for pid-13653 exe-/bin/cat 
name-shadow dev-hda6 ino-1361441 
scontext-root:staff r:staff t 

tcontext-system u:object r:shadow t tclass-file 


A cat program, amelynek a biztonsági környezeti címkéje 
esetünkben root: staff. r:staff. t, nem kapta meg az 
engedélyt egy system u:object r:shadow t címkéjű fájl 
olvasására. 

A SELinuxnak természetesen halvány fogalma sincs arról, 
hogy mi az a cat vagy mit tartalmaz a /etc/shadow fájl, őt 
egyszerűen csak a megfelelő biztonsági környezeti cím- 
kék, a célobjektum (ebben az esetben a fájl) osztálya és az 
éppen kérelmezett engedély típusa érdeklik. Az ezekkel 
megadott információ számára tökéletesen elegendő a dön- 
tés meghozatalához. 

A SELinux tervezésében fontos szempont, hogy a címkék 
az objektumok összes biztonsági jellemzőit magukban fog- 
lalják. A rendszermagban a biztonsági kiszolgáló, a felhasz- 
nálói térben pedig a libselinux értékeli ki azokat a megfelelő 
pillanatokban. Maga a rendszermagkód és a felhasználói tér 
többi része semmi egyebet nem tesz, csupán számára isme- 
retlen adatként továbbadja a címkéket. Ennek a rendszer- 
nek az egyik óriási előnye az, hogy a címkéket anélkül lehet 
újabb biztonsági jellemzőkkel kiegészíteni, hogy ehhez újra 
kellene fordítani az alkalmazásokat vagy újratervezni az 
alapvető SELinux kódot. 


Kiterjesztett jellemzők 

Egy jellegzetes lemez alapú Linux fájlrendszerben minden 
fájlt egyedileg azonosít egy olyan fájlleíró, amely a fájl 
kulcsfontosságú adatait tartalmazza, beleértve a LINIX tu- 
lajdonjogot és a hozzáférési adatokat. Amikor a rendszer- 
mag egy fájlra hivatkozik, akkor a lemezről a memóriába 
olvassa ezt a fájlleírót. A LINIX szabványos jogosultság- 
ellenőrzése egyszerűen a fájlleíróban szereplő adatokat 
használja. A SELinux tulajdonképpen ezt a szabványos 
UNIX biztonsági protokollt terjeszti ki, és biztonsági kör- 
nyezeti címkéket használ a finomított hozzáférés-szabályo- 
zási döntések meghozatalára. 

Maga a Linux megvalósítja a kiterjesztett jellemzőket 
(Extended Attributes — EAs), más néven EAs vagy xattrs. 
Ezek a név/érték párok fájlokhoz rendeltek, akár a kiterjesz- 
tések a hagyományos fájlleíró alapú jellemzőkhöz. A kiter- 
jesztett jellemzők segítségével úgy lehet szabványosított 
módon szolgáltatásokat adni a fájlrendszerekhez, hogy 

a jellemzők felületei fájlrendszerektől függetlenek legye- 
nek. A kiterjesztett jellemzőkkel kapcsolatos szolgáltatások 
közé tartoznak például a hozzáférés-szabályozási listák 
(Access Control Lists — ACL), a karakterkészletleíró-adatok 
tárolása a fájladatok mellett és a SELinux biztonsági kör- 
nyezet címkézés. 

A kiterjesztett jellemzők a névtereken belül tárolód- 

nak, lehetővé téve ezzel a különböző osztályokba tarto- 
zó kiterjesztett jellemzők elkülönített kezelését. A hozzá- 
férésszabályozási listák a sysstem.posix ac] access 

és a system.posix acl. default névterekben kapnak 
helyet. A SELinux biztonsági környezeti címkéi 

a security.selinux namespace névtérben találhatóak. 
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1. ábra Az SELinux hozzáférés-szabályozási döntései 
a rendszermagban 


Akit részletesebben is érdekelnek a Linux kiterjesztett biz- 
tonsági jellemzői az olvassa el az attrC(5) súgóoldalt. 


Kiterjesztett jellemzők biztonsági címkézése 

A kiterjesztett jellemzők természetesen , kézzel" is módosít- 
hatók a getfattrC(1) és a setfattrC1) segédprogramokkal. 
Ha például látni akarjuk egy fájl SELinux biztonsági kör- 
nyezeti címkéjét, akkor a következőt kell tennünk: 


$ getfattr -n security.selinux /tmp/foo 
getfattr: Removing leading /" from absolute 
spath names 

ff file: tmp/foo 

security.selinux-"root:object r:sysadm tmp. tV900"7 


Figyeljük meg a kiterjesztett jellemző biztonsági névteré- 
nek leírását! A rendszer használatát megkönnyítendő 

a SELinux-hoz kapunk egy getfilecon(1) nevű burkoló- 
programot is, ami bizonyos helyzetekben nagyon meg- 
könnyítheti az életet. Segítségével ugyanis nem nekünk kell 
meghatározni a kiterjesztett jellemző névteret, és tisztább 
eredményt is ad. 

A szöveg alapú címkék használata biztosítja, hogy értelmes, 
olvasható biztonsági jellemzők tárolódjanak a fájladatokkal. 
Ezek a címkék változatlanok maradhatnak vagy lefordítha- 
tók, ha a fájlrendszer egy másik, valószínűleg más biztonsá- 
gi rendet alkalmazó rendszerre fűződik be. Ennek ellenpél- 
dája, ahogy a fájl tulajdonosa felhasználói számazonosító- 
ként tárolódik a fájl leírójában. A felhasználói azonosító 
jellemzően egy értelmes értékhez van hozzárendelve az 
letc/passwd tájlon keresztül — egy másik rendszerben más 
jelentése lehet. 

Ahhoz, hogy egy fájlrendszer támogassa a SELinux biz- 
tonsági környezet címkéket, kiterjesztett jellemző támoga- 
tásra és kiterjesztett jellemző biztonsági névtér kezelőre 
van szüksége. Jelenleg az ilyen fájlrendszerek közé tarto- 
zik az exf3, az exf2, az XES és a ReiserES -— ez utóbbi külső 
foltot alkalmaz. Ráadásul a devpts fájlrendszer hamis biz- 
tonsági kezelővel rendelkezik, amely megengedi a kiter- 
jesztett jellemző alapú hozzáférést a pty-k rendszermag- 
ban található címkéihez. 

Tehát, mikor kerülnek címkézésre a fájlok? A SELinux rend- 
szer telepítése során, a setfiles(8) segédprogram jellem- 
zően arra szolgál, hogy a fájlrendszer összes olyan fájlját 
megcímkézze, amely támogatja a kiterjesztett jellemző biz- 
tonsági címkézést. Az olyan csomagkezelő eszközök, mint 
az RPM, szintén megcímkézhetik a fájlokat a telepítés s0- 











rán, a rendszergazdáknak viszont gyakran kézzel kell 
beállítaniuk a biztonsági környezetet, a chcon(1) vagy 
a setfilecon(1) segédprogrammal. 


Fájlok létrehozása 

Amikor létrejön egy fájl, a biztonsági rend egy megfelelő 
szabálya általában leírja, hogyan kell címkét hozzárendelni 
a szülőkönyvtár és az aktuális feladat biztonsági környezete 
alapján. Íme egy példa: 


$ id -Z 

root:staff r:staff t 
$ 1s -dzZ /tmp 
drwxrwxrwt- root 
/tmp 

$ touch /tmp/hello 
$ getfilecon /tmp/hello 

/tmp/hello root:object r:staff tmp t 


root system u:object r:tmp. t 


Ebben az esetben a biztonsági rend egy olyan szabályt 
tartalmaz, amely megszabja, hogy a staff t által a tmp. t 
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könyvtárban létrehozott fájlokat a staff. tmp. t típus 
címkével kell ellátni. Ha nincs egyértelmű szabály, 

akkor a fájlokat a szülőkönyvtár környezetével kell 
megcímkézni. 

A kitüntetett alkalmazások felülbírálhatják az imént 
említett szabályt, úgy, hogy biztonsági környezetet írnak 

a /proc/self/attr/fscreate fájlhoz. Ezután ez a biztonsági 
környezet szolgál az összes újonnan létrehozott fájl meg- 
címkézésére. A setfscreation(3) könyvtárfüggvény 
magában foglalja ezt a lehetőséget. Ahhoz, hogy kézzel 
visszaállítsunk egy biztonsági környezetet, használjuk 

a restorecon(8)-t. 

Az olyan helyzetek kezelésére, amikor címke nélküli fájlok 
keletkeznek, fejlesztés alatt áll egy fsck-szerű segédprog- 
ram. Ez az indításkor futtatandó alkalmazás biztosítja majd, 
hogy minden fájl helyesen címkézett, mielőtt több felhasz- 
nálós üzemmódba lép. 


Viselkedésmódok címkézése 

Az előző részben az olyan fájlrendszerekben való fájlcímké- 
zésről volt szó, amelyek támogatják a lemezen található ki- 
terjesztett jellemzőket, és rendelkeznek kiterjesztett jellem- 
ző biztonsági névtér kezelővel. Amikor egy ilyen fájlrend- 
szer helyesen van befűzve, akkor úgy mondják, hogy 

a xattr címkéző viselkedésmódot alkalmazza. 

Amikor a SELinux kezdeti értéket ad egy fájlrendszernek, 
például a befűzés során, a következő naplóüzenet keletkezik: 


SELinux: initialized (dev hda6, type ext3), uses 
xattr 


A uses xattr záradék azt jelenti, hogy a fájlrendszer a fent 
leírt xattr címkéző viselkedésmódot alkalmazza. Sok fájl- 
rendszer nem támogatja a kiterjesztett jellemzőket, és azok 
közül, amelyek támogatják, sem mind rendelkezik bizton- 
sági névtér kezelőkkel. A lemezes fájlrendszereknél lehet, 
hogy még senki sem végezte el a kódolási munkát, vagy 
egyszerűen a kiterjesztett jellemzőknek nincs értelme 

a vfat-hez hasonló öröklött fájlrendszereken. 

A pszeudo-fájlrendszerek burjánzása a Linux alatt kezdő- 
dött. A fájlrendszerek egyre kedveltebb felhasználó-rend- 
szermag alkalmazásprogramozói felületté válnak. Ezek közül 
a procfs a legszembetűnőbb, amely a felhasználói tér és kü- 
lönböző rendszermag-összetevők közötti felület. A procfs 
hosszú történetének köszönhetően rengeteg hulladékot hal- 
mozott fel, és az új felhasználó-rendszermag alkalmazás- 
programozói felületeket arra ösztönzi, hogy különböző fájl- 
rendszerekként valósuljanak meg. Ezek a fájlrendszerek 

a rendszermagra épülnek, és nincs valódi kiterjesztett jellem- 
ző támogatás. Ilyen például az usbfs, a sysfs és a selinuxfs. 

Az ilyen kiterjesztett jellemzőket nem támogató rendszerek 
különböző címkézési viselkedésmódokat használnak, az 
egyes fájlrendszer-fajták biztonsági rendjéhez igazodva. 

Az átmeneti SIDS címkézési viselkedésmód a devpts, tmpfs 
és shmfs fájlrendszereknél használatos. Az ezekben a fájl- 
rendszerekben található fájlok igény szerint a rendszermag- 
ban kerülnek címkézésre, az adott feladat és az érvényben 
lévő fájlrendszer biztonsági környezete alapján. 

A devpts egy különleges átmeneti SIDS fájlrendszer. Kiter- 
jesztett jellemző alkalmazásprogramozáói felület elérést biz- 
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tosít a pty-khez egy álkiterjesztett jellemző biztonsági keze- 
lőn keresztül. A kitüntetett alkalmazások, mint amilyen az 
sshd ezt a szolgáltatást a pty-k újracímkézésére használja, 
az átmeneti SID címkék felülbírálásával. 

A SIDS címkézési viselkedésmód feladat egyszerűen 
megcímkézi az aktuális feladattal azonos biztonsági kör- 
nyezetben lévő fájlt. A pipefs és a sockfs fájlrendszerben 
létrehozott csővezetékek illetve csatlakozópontok esetében 
használatos. 

A genf. contexts címkézési viselkedési módot olyan fájl- 
rendszereknél használják, amelyek alkalmatlanok az xattr, 
átmeneti SIDS és feladat SIDS címkézésre. A biztonsági 
rendben a biztonsági környezet címkék fájlrendszer/elérési 
út párokhoz vannak rendelve. Az elérési út összetevő célja, 
hogy lehetővé tegye a fájlrendszer finomabb léptékű címké- 
zését. Ez a szolgáltatás különösen a procfs-nél fontos, 
amely olvasható és írható rendszermag-adatok össze- 
visszasága, beleértve a sysfc! felületet. 

A legtöbb nem kiterjesztett jellemzős fájlrendszer 

a genf. contexts címkézést használja, általában úgy, 

hogy az egész fájlrendszer egyetlen biztonsági környe- 
Zetre van állítva. Ennek gyakori példája a sysfs, a vfat, 

az nfs és az usbdevfs. 


Befűzési pont címkézése 

A 2.6.3-mas rendszermagba újonnan került szolgáltatás 

a befűzési pont címkézése, vagy másként a környezet- 
befűzés. Ennek az a fő célja, hogy lehetővé tegye, hogy 

az egész fájlrendszer biztonsági környezetét meg lehessen 
határozni egy befűzési beállítással. A befűzési pont címké- 
zése bármilyen fájlrendszerre megvalósítható, és felülbírál- 
ja a rendes címkézési viselkedésmódot. 

A befűzési pont címkézésének egy meghatározott fel- 
használási módja annak lehetővé tétele, hogy a különböző 
NES beftűzések külön-külön lehessen címkézni, befűzési 
időben. Olyan fájlrendszerek általános esetenkénti címké- 
zéséhez is hasznos, amelyek nem támogatják a kiterjesz- 
tett jellemző biztonsági címkézést, valamint máshol cím- 
kézett kiterjesztett jellemző címkézésű fájlrendszerek 
címkézésére. Ez utóbbi például a törvényszéki munkában 
lehet hasznos. 

A címke nélküli öröklött fájlrendszereket is lehet, hogy 
SELinuxra alkalmas operációs rendszereken kell befűzni. 
Ugyan a fájlrendszertípus támogatja a kiterjesztett jellem- 
ző biztonsági címkézést, esetleg nem akarunk maradandó 
biztonsági környezet címkéket adni a fájlrendszerekhez. 
A betfűzési pont címkézése segítségével rendszermag 
alapú címkéket rendelhetünk hozzá, amelyek nem íród- 
nak a lemezre. 

Mivel a befűzési pont címkézése új szolgáltatás, és nem 

elég alaposan dokumentált, vegyük egy kicsit részletesebben. 
Amikor a SELinux engedélyezett a rendszermagban, 
három új lehetőség válik elérhetővé a befűzési pont cím- 
kézése számára: 


e context: A fájlrendszer összes fájlját és magát a fájl- 
rendszert a meghatározott biztonsági környezet sze- 
rint címkézi. A /proc/self/attr/fscreate alkalmazásprog- 
ramozói felületet, amelyet fent taglaltunk, a fájlrend- 
szer figyelmen kívül hagyja. Ez felülbírálja a meglévő 


26 Linuxvilág 





címkézési viselkedésmódot, és a befűzési pont címké- 
zésére változtatja. Ezzel a lehetőséggel a fájlrendszer 
címkéi a felhasználó számára kizárólag olvashatóak, 
annak ellenére, hogy a házirend által meghatározott 
átmenetek még működnek azokon a fájlrendszereken, 
amelyek támogatják a kiterjesztett jellemző biztonsági 
címkézést. 

fscontext: A teljes fájlrendszer címkéjét (azaz 

a fájlrendszert magát) beállítja a meghatározott biz- 
tonsági környezetre állítja. Ez lehetővé teszi a fájl- 
rendszerek finomabb léptékű vezérlését, azáltal, hogy 
hozzájárul, hogy a címkéket a befűzés alapján lehes- 
sen beállítani, a házirendben meghatározott fájlrend- 
szer alapú beállítás helyett. Mivel a context lehetőség 
is ezt a működést valósítja meg, nem lehet együtt 
használni a két lehetőséget. Ez a beállítás csak 

olyan fájlrendszereken működik, amelyek támogatják 
a kiterjesztett jellemző biztonsági címkézést. A teljes 
fájlrendszer biztonsági környezetei egy adott fájl- 
rendszeren belül, a fájlok létrehozása során hozott 
hozzáférés-szabályozási döntéseknél, fájlrendszerek 
befűzésekor és leválasztásakor, fájlrendszer-jellemzők- 
höz való hozzáféréskor és maga a fájlrendszer újra- 
címkézésekor használatosak. 

defcontext: Beállítja a címkézetlen fájlok alapértelme- 
zett biztonsági környezetét a házirendben meghatáro- 
zott érték helyett. Ahogy az fscontext lehetőségnél is, 








csak olyan fájlrendszerekkel működik, amelyek támo- 
gatják a kiterjesztett jellemző címkézést, és érvénytelen, 
ha a context lehetőség van meghatározva, mivel az is 
ezt a működést valósítja meg. 


A rendszermagban a SELinux a mount (2) alatt elemzi és ki- 
iktatja a biztonsági befűzési beállításokat, rendes beállításo- 
kat átadva a fájlrendszerfüggő kódon keresztül. A hagyo- 
mányos fájlrendszereknél nem kell ügyelni a biztonsági be- 
állításokra, így nincs szükség a módosításokra. Ez azért le- 
hetséges, mert a legtöbb fájlrendszer általában név/érték 
párokat használ befűzési lehetőségként, amelyet a SELinux 
könnyen befolyásolhat. 

A bináris befűzési beállítás adatokkal rendelkező fájl- 
rendszerek esetében, amilyen a NFS, az SMBES, az AFS 

és a Coda, különleges módon kell eljárni. Ezek közül csak 
az NFSv3 támogatott a SELinux fejlesztésének mostani 
szakaszában. 

Íme egy példa, a context lehetőség működésére, mivel 
valószínű, hogy a három befűzési lehetőség közül ez 

a leggyakrabban használt. Egy naplófájlokat tartalmazó 
hajlékony lemez érkezett az asztalunkra, és szeretnénk 
befűzni a SELinux gépre, néhány elemző programot fut- 
tatni rajta. Amiatt, ahogy a házirend meg van határozva, 
a fájlokat a system u:object r:var. log. t címkével kell 
ellátni, hogy a naplóelemző program megfelelően mű- 
ködjön. Ha ezzel a módszerrel fűzünk be, elkülöníthetjük 
az adatot a lemezen, lehetővé téve a SELinuxnak, hogy 
megvédje egymástól az operációs rendszert és a lemez 
tartalmát. 

Fűzzük be a lemezt: 


$ mount -v -t vfat 

5-o context-system u:object r:var log t 

5 /dev/fd0O /mnt/floppy 

/dev/fd0O on /mnt/floppy type vfat 
(context-system u:object r:var log t) 

Mit mond az ellenőrzési napló? 

SELinux: initialized (dev fdO, type vfat), uses 
mountpoint labeling 


Ez az üzenet ígéretesnek tűnik. Következőnek ellenőrizzük, 
hogy a lemez fájljai úgy vannak címkézve, ahogy gondol- 
tuk. Rendszerint a getfilecon(1) hívást alkalmaznánk, 

de a getfattr(1) egyértelműbb hibaüzeneteket ad: 


$ getfattr -n security.selinux 
/mnt/floppy/access log 
/mnt/floppy/access log: security.selinux: 
s operation not supported 


Mi történik? Egy 1s -Z parancs is megmutatja, hogy a fájl 
üres biztonsági környezettel rendelkezik: 


$ 1s -Z /mnt/floppy/access log 
-rwxr-xr-xt root root (null) 
5 /mnt/floppy/access log 


A hajlékonylemezen található vfat fájlrendszer nem ren- 
delkezik kiterjesztett jellemző támogatással, és a bizton- 
sági környezet címkézése tisztán a rendszermagon belül 
történik. Kiderül, hogy a rendszermagon belüli címkézés 
jól működik, de a felhasználói tér eszközei nem képesek 
megjeleníteni a kiterjesztett jellemző alkalmazásprogra- 
mozáói felületen található címkéket. Ez az aktuális kiter- 
jesztett jellemző megvalósítás korlátja, amelyet még ele- 
gánsan meg kell oldani. 

Van viszont egy trükkös módja, hogy megnézzük, 

mik a fájlok címkéi — az ellenőrzési napló alkalmazásá- 
val, amely hozzáférési üzenetek naplózásakor mindig 
rögzíti a célobjektum biztonsági környezetét. 

A getfattr(1) használata a következő ellenőrzési 
bejegyzést idézte elő: 

avc: denied ( getattr 3 for pid-12354 
exe-/usr/bin/getfattr 

path-/mnt/floppy/access log dev-fd0O ino-132 
scontext-root:staff r:staff t 

tcontext-system u:object r:var log t tclass-file 


Tehát a fájl címkézése helyes 
(system u:object r:var log t), amely a context befűzési 
lehetőségen keresztül került a befűzés parancshoz. 


Jövőbeni munka 

Most is lehet ugyan biztonsági környezeti címkéket rendelni 
az NFS-sel befűzött fájlrendszerekhez, de azok csak helyben 
működnek, a rendszermagon belüli hozzáférés-szabályozási 
döntéseknél. A címkék nem kerülnek átvitelre a hálózaton 

a fájlokkal együtt. Ezen a területen fejlődés tapasztalható az 
NEFSv2/v3 protokollokon és kódon történt SELinuxra szabott 
módosításoknak köszönhetően. Hosszabb távon az NFSv4- 
be várhatóan bekerül a hálózati címkézés nevesített jellem- 
zőkön keresztül, amelyek részei a kiterjedtebb NFSv4 leírás- 
nak. Ez lehetővé tenni, hogy az NFS ügyfél is és a kiszolgáló 
is megvalósítsa a SELinux biztonságot a hálózati fájlokon. 
Más hálózati fájlrendszerek számára szintén hasznos lenne 
a támogatás, ahogy a TIrusted BSD SELinux kapujával való 
együttműködés is. 
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Az SOL és az Nmap szövetsége: hatékonyság 


és kényelem 


Ha az Nmap-et használjuk a hálózaton lévő gépek biztonságának ellenőrzésére, 
akkor érdemes a MySOL-re bíznunk a trendek és változások nyomon követését. 


evelet váltottam nemrég valakivel, akinek rendszeres 
L kapupásztázást kell végeznie a hálózatán a sebezhető 

pontok felderítése végett. Az általa használt kapu- 
pásztázó segédprogram az Nmap, ami azonban maga nem 
teszi könnyen kezelhetővé az általa szolgáltatott adatokat. 
Ez bizony már egy teljesen más terület. Néhány héttel ké- 
sőbb elkészült az Nmaphez egy olyan folt, amely lehetővé 
tette az eredmények MYySOL adatbázisban történő rögzíté- 
sét. Bár az Nmap támogatja a mind a géppel elemezhető, 
mind pedig az XML kimeneti formátumot, az SOL-adat- 
bázisba történő naplózás kényelme és hatékonysága messze 
meghaladja az XML, de még a géppel elemezhető kimeneti 
formátum képességeit is. Hogy csak egy dolgot említsek, az 
nmapsgl nem tartalmaz külön lépést a parancshéjban a ki- 
menet utófeldolgozó egységbe való áttöltésére. 
Az nmapsgl egy közvetlen folt a Fyodor által megalkotott 
tiszteletre méltó Nmap hálózatpásztázó program 3.48-as 
változatához. (Amikor ezt írom, már megjelent az Nmap 
3.50-es változata, amelyhez egy frissített nmapsgl is letölt- 
hető a program honlapjáról.) A folt tartalmaz MySOL- 
támogatást, de az eredmények egyszerű átvitelén kívül sok- 
kal többre is képes: célmegjelölést, pásztázó-kijelölést, és 
egyszerű összehasonlító kiértékelést (trending) is lehetővé 
tesz. Az adatok SOL-adatbázisba való áttöltésével egy sereg 
új feladat elvégezhető. Az nmapsgl a 5 sourceforge.net/ 
projects/nmapsgl címről tölthető le. A program az adatkeze- 
léshez jelenleg a MySOL ügyfélprogramjának felhasználói 
felületét alkalmazza. 
Mivel a hálózati biztonságért felelős rendszergazdák nem 
feltétlenül adatzsonglőrök, az nmapsgl tervezésekor fontos 
szempont volt az egyszerű kezelhetőség. A folt működése 
elég egyszerű ahhoz, hogy a hálózatvizsgálat eredményé- 
nek legfontosabb információi egyetlen táblából kinyerhetőek 
legyenek. Az egyszerűség az oka annak is, hogy az IP-címek 
tárolása formázatlan szövegként és nem inet. atonO jelö- 
lésben történik. Ismerem a szövegkezelés teljesítményben 
megmutatkozó hátrányait, de most a kis adathalmazok ké- 
nyelmes kezelésének bemutatására összpontosítunk. Nagy 
adathalmazok esetén, amikor a sebesség kérdése kritikus 
szempont, a célmegjelölő címkék, futási és pásztázó-azono- 
sítók állnak rendelkezésre a numerikus keresés számára. 
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A cikkben először egy SOL-t használó hálózatpásztázás- 
sal foglalkozunk, amellyel egy hálózat nyitott kapuit és 
élő célgépeit derítjük fel. Ezután az SOL-ben összegyűj- 
tött adatokra vetünk egy pillantást és megvizsgáljuk, 
milyen módszerekkel lehet a kapott eredményeket össze- 
hasonlítani. 


A beállítási lehetőségek 

Az nmapsgl tevékenységét az aktuális felhasználó saját 
könyvtárában lévő -/nmapsgl.rc fájl beolvasásával kezdi. 
Ez azt jelenti, hogy ha az nmapsal futtatása előtt a su - 
parancsot használjuk a rendszergazdai jogosultság meg- 
szerzéséhez, a beolvasott fájl a /root/nmapsgl.rc lesz. 
Egyelőre mindössze négy tétel szerepel az nmapsgl.rc fájl- 
ban, mindegyik külön sorban, adat-érték formátumban, 
ahogy sok más programnál is láthatjuk. A tételek a kö- 
vetkezők: 


server-localhost, 
db-nmaplog, 
user-nmap, 
passwd-scanamanga 


A server annak a gépnek a DNS-neve, amelyen a MySOL 
fut, a db pedig ezen a kiszolgálón található adatbázis neve. 
A user és password tételek az adatbázishoz való csatlako- 
záshoz szükséges felhasználói név és jelszó. Az itt szereplő 
felhasználónak az adatbázison legalább SELECT, INSERT és 
UPDATE jogosultságokkal kell rendelkeznie. 

Az Nmap által biztosított parancssori lehetőségeket az 
nmapsgl négy további paraméterrel egészíti ki: 


--mysagi 
--runid 
--targetid 
--scannerid 


Ha az nmapsgl futtatható állományát ezek nélkül a paramé- 
terek nélkül indítjuk, a működése teljesen megegyezik az 
Nmap működésével. Ezen beállítások egyike sincs hatással 
az Nmap létező paramétereire, így semmi akadálya annak, 











1. lista Az Nmap kimenetének egy részlete 


Starting nmap 3.48 ( 

http: //ww. insecure.org/nmap/ ) 

at 2003-12-14 10:00 SGT 

Insufficient responses for TCP seguencing (1), 
os detection may be less accurate 

Interesting ports on 192.168.10.0: 

(The 1656 ports scanned but not shown below are 
in state: closed) 

PORT . STATE SERVICE VERSION 

80/tcp open http? 

Device type: print server 

Running: Linksys embedded 

os details: Linksys EtherFast print server 


Interesting ports on wap.hasnains .com 
CI9ZZ SSE TOST) 

(The 1654 ports scanned but not shown below are 
in state: closed) 


PORT — STATE SERVICE VERSION 
21/tcp open ftp? 

23/tcp open telnet? 

80/tcp open http 

Device type: broadband router 


Running: Zyxel ZyNOS 
os details: ZyXEL Prestige 700/Netgear MA314 
broadband router 


hogy ugyanannak a hálózatvizsgálatnak az eredményét 
egyidejűleg SOL-adatbázisba és gépileg elemezhető kime- 
netre irányítsuk. 

A --mysg1 kapcsolót a többi nmapsg! kapcsoló nélkül hasz- 
nálva a parancssorban olyan MySOL-naplózás indul el, 
amelynek során minden címke- és azonosító-kijelölés ön- 
működően történik. Az összes többi nmapsgl paraméter fel- 
tételezi a --mysg1] használatát. Az önműködő kijelölés során 
a folyamat veszi a megfelelő tábla legnagyobb értékét és 
egyesével halad az értékeken. 

A pásztázó azonosító megadásának lehetőségét bevezető 
--scanner-id xxx paraméter, amelyben az xxx az azonosító 
értékét jelöli, olyan helyzetek esetében alkalmazhatók, ami- 
kor több pásztázó kerül üzembe helyezésre, például egy 
több alhálózattal rendelkező környezetben. A pásztázó-azo- 
nosító (scanner ID) és a futásidejű azonosító (runtime ID) 

a portstat táblában tárolódik lehetővé téve a pásztázást 
végző gép számára az eredményhalmazok különválasztá- 
sát. Az alábbi lekérdezés használatával így egyszerűen 
különválaszthatnánk például a tízes pásztázó eredményeit: 


mysgl:s select " from portstat 
-s5 where scannerid - 10 and runid -— 100; 


A --run-id xxx paraméter az nmapsgl adott futtatásához 
rendelt azonosító megadására szolgál. Amennyiben nem 
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használjuk ezt a lehetőséget, a rendszer önműködően 
hozzárendelt azonosítót használ. Ha a megadott futtatás- 
azonosító már szerepel az adatbázisban, ismételten felhasz- 
nálásra kerül. Ez a lehetőség biztosítja, hogy különböző fut- 
tatások eredményeit kényelmesen csoportosíthassuk egy 
futtatási azonosító alatt. 

A futtatás-azonosító (runtime ID) és a hozzá kapcsolódó in- 
formációk tárolására a runlist tábla biztosít helyet. A hasz- 
nált táblák ismertetését , Az nmaplog által használt táblák" 
című kiemelt részben láthatjuk. A vizsgálat befejeztével fris- 
sül a futásidejű információk egy része, köztük a parancssor- 
ban megadott összes lehetséges célpontok és a működő ál- 
lapotban találtak száma. Hasonlóan tárolódik a pásztázó 
azonosítója (scanner ID) és az ehhez kapcsolódó informáci- 
ók a scanners táblában. 

Minden vizsgált célpont egy címkét kap, az információ 
pedig a targets táblába kerül. A futási listához hasonlóan 

a targets tábla is két szakaszban kerül feltöltésre. Az első 
szakasz az IP-címeket és — amennyiben feloldható — a gép- 
neveket gyűjti be, a második szakaszban pedig az 

os. guessed oszlop feltöltése történik. Pillanatnyilag nem 
tárolódik egy fel nem ismert operációs rendszer ujjlenyo- 
mat-információja, de a jövőben változhat a helyzet. 

A targets táblában sosem jönnek létre kettőződések. 
Tapasztalatom szerint csak abban az esetben lehetnek kettő- 
zött IP-alhálózatok, amennyiben egyik ügyféltől a másikhoz 
helyezzük át a rendszert. Ebben az esetben minden ügyfél 
esetén különböző adatbázisra van szükség. 

A célazonosítókat (target ID) pillanatnyilag még nem hasz- 
nálja a rendszer, de a felhasználónak a parancssorban lehe- 
tősége van saját célazonosító meghatározására. Amennyi- 
ben a megadott azonosító már létezik, az egyediség megőr- 
zése érdekében a rendszer figyelmen kívül hagyja és egy 
rendszer által előállított azonosítót használ helyette. 

Ha a parancssorban a --target-id után megadott célazo- 
nosító még nem szerepel a targets táblában, hozzárende- 
lődik az adott cél IP-címéhez. Ha több rendszer számára 
történik a célmegadás, az első cél kapja meg a megadott cél- 
azonosítót, a rá következőkhöz pedig az eggyel növekvő 
azonosítók fognak tartozni. 


Az alapok 

Az nmapsgl rögzíti a naplóban a futtatás dátumát és idő- 
pontját, az Nmap-et futtató felhasználó nevét, a futtató gép 
nevét, és a futtatáshoz rendelt azonosító számot. A két 
utóbbi adat lehetővé teszi, hogy az nmapsgl-t nagyobb 
rendszerekben is alkalmazzuk és alapot képeznek az egyes 
vizsgálatok összehasonlítására. A futtatás-azonosító (runid, 
runtime ID) az adathalmazon belül mindig egyedi. Ha 

a megadott cél azonos, két vizsgálati eredmény között a fut- 
tatás-azonosító alapján tehetünk különbséget, lehetőség 
van azonban arra is, hogy több vizsgálati eredményt cso- 
portosítsunk oly módon, hogy a pásztázáshoz a --run-id 
kapcsoló segítségével egyetlen futtatás-azonosítót adunk 
meg. Vizsgáljuk meg például az nmapsg!1 alábbi indítását: 


$ nmap -A --mysg] --runid 100 192.168.10.1/24 


A parancs a naplózási lehetőséget engedélyező --mysa1 kap- 
csolóval indítja el az Nmap-et, a futtatás-azonosító értékének 
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2. lista Egy adott pásztázás eredménye 








-4—————————————————— -4—-—————————— 4—-————— 
] target ip d t 

4 —————— -4——————————— 4—-——————— 
1 192.168. 1080 2003-12-14 TOZO0ÉSZ 
I! 192.168. 1084 2003-12-14 TOSOOSZZ 
INKESZSTSSSLOS 1 2003-12-14 TOSOO: 37 
[ELSZETSSÉLOS 2003-12-14 TOSOOZSTZ 
] 192.168.10.44 2003-12-14 TOSO0SSTZ 
] 192.168.10.44 2003-12-14 TOSO0ÉSZ 
] 192.168.10.44 2003-12-14 10:00:37 
] 192.168.10.44 2003-12-14 TOZO00:37 
[ELSZELSSÉTOS6SZ 2003-12-14 105005 574 
] 192.168.10.64 2003-12-14 105015 577 
] 192.168.10.64 2003-12-14 TOSO0ÉSZ 
[d92-168-10264 2003-12-14 TOSOOSSTZ 
[/ASZTOST064 2003-12-14 TOSO0SSZ 
] 192.168.10.64 2003-12-14 JOZO0ÉSZ 
[ELSZETSSÉTLOT6Z 2003-12-14 105015 37/ 
] 192.168.10.64 2003-12-14 TOSO0S 37 
I 4192.168.10-64 2003-12-14 TOSOOSZZ 
[ASZ tSsét0:6sS 2003-12-14 TOSO0SSTZ 
KELSZETSSÉTOÉSS 2003-12-14 105005 577 
[KESZ ETSSÉTOS6S 2003-12-14 105005 577 
[ELSZSTSSÉTOSSS 2003-12-14 TOZOOSZZ 
[KELSZ SSÉTOSSS 2003-12-14 ÜOSOOSSTZ 
-4———————————————— -4——————————— 4—-———— 


100-at ad meg és megvizsgálja a 192.168.10.1/24 hálózatot. 
Amennyiben ez az nmapsagl! első futtatása, egy összehasonlí- 
tási alap jön létre a hálózat számára, amelyhez a későbbi fut- 
tatások eredményeit hasonlíthatjuk. Az nmapsgi emellett ön- 
működően létrehoz a futtató gép számára egy bejegyzést, 
ebben az esetben a 192 .168.10. 44 értékkel, amelyet hozzá- 
rendel a scanners tábla egy scanner. id mezőjéhez. Az 1. lis- 
tán a futtatás konzolkimenetének részlete látható. 

A cél meghatározása ebben az esetben a teljes C-osztályú 
alhálózatot jelenti. Az nmmapsgl önműködően egyedi azono- 
sítókat rendel a hálózaton talált minden működő géphez, és 
további információkat is tárol a hoststats táblában. Önma- 
gában már ez a tábla is kiinduló eszköz lehet egy kapupász- 
tázás-összehasonlításhoz. 

Vizsgáljuk meg röviden, hogy milyen adatok kerültek rögzí- 
tésre. Ehhez először is bejelentkezünk a MySOL ügyfélprog- 
ramjába és csatlakozunk az nmapsgl.rc fájlban megadott 
adatbázishoz. Ezután a következő lekérdezést futtatjuk: 


$ mysg] nmaplog -p 

mysgl: select target ip, d, t, port, protocol, 
-s5 state, runid from portstat 
-s5 order by target ip, d, t ; 


A lekérdezés a 2. listán látható táblázatot adja eredményül, 
egy tetszetős listát, amelyben az adatok a cél IP-címe, a dá- 
tum és idő szerint rendezett sorrendben jelennek meg. Lát- 
ható, hogy a runid oszlop tartalma minden esetben 100, 
ahogy azt a parancssorban megadtuk. 
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aa százázlsázllstai tsasszts kzásstzáemtetzlgtsi úlzssásánlsásli HE 
port protocol ] state TET! I 
aze ezazat Zaza szüdst Sade zazede JESS SSSSZS a 
80 tcp ] open ] 100 I 

21 tcp ] open ] 100 I 

23 tcp ] open I5ELŐ0 I 

80 tep ] open (5000 I 

22 tép ] open ] 100 I 

0 tEp ] open ] 100 I 

3306 tép l] open ISÉL00 I 
6000 ep ] open (ELO I 

135 tcp ] open ] 100 I 

139 tEp ] open AK I 

445 tcp ] open 16KŐ I 

I 1024 tép ] open ISEL00 I 
1025 tep ] open (LOG I 
08 tcp ] open ] 100 I 
5000 Ep ] open NLG] I 
S40M ep ] open ] 100 I 
6000 tép ] open (ÉL00 I 

135 Ep ] open ] 100 I 

139 Ep ] open ] 100 I 

445 Ep ] open 1KEÜDŐI I 

1025 tcp ] open (ELÖŐ I 
5000 tep ] open I 00 I 

ESZ Sz zzz GEES ZSE S ES SSZzzaae kt SSE TSZz ek e 


A következő lekérdezés futtatásával a 3. listán látható, 
a 192.168.10.44 cím nyitott kapuira vonatkozó informáci- 
ót kapjuk: 


mysgl: select target ip, d, t, port, protocol, 
-s5 state, runid from portstat 
-5 where target ip - "192.168.10.44" 
-s5 order by d, t; 


Ha a kapott négy sort hozzáillesztjük az 1. lista 
192.168.10.44 címre vonatkozó szakaszához, azonnal felis- 
merhetjük a köztük fennálló kapcsolatot. Látszik, hogy 

a portstat tábla önmagában is tartalmazza az Nmap által 
kapupásztázásra vonatkozóan szolgáltatott összes informá- 
ciót. Természetesen ha már több futtatási eredménnyel ren- 
delkeznénk, a fenti lekérdezés a 192.168.10.44 címre vo- 
natkozó minden adatot kilistázná. 

Tegyük fel, hogy két nap, egy hét, esetleg egy hónap eltelté- 
vel újra megvizsgáljuk a hálózatot és az eredményeket vi- 
zuálisan is össze szeretnénk hasonlítani. A runlist táblára 
vetett első pillantásra látható, hogy a két nappal későbbi 
vizsgálatnak a 102-es futtatás-azonosító felel meg. Ennek 

az információnak a felhasználásával már írhatjuk is a lekér- 
dezésünket: 


mysgl: select target ip, d,t,port, protocol, 
-s5 state from portstat 
-5 where target ip - "192.168.10.44" 
-s5 and runid - 102 order by d,t,port; 


3. lista Egy adott gép vizsgálatának eredményei 


sss e massage zta aaa maaa a-zsszssssas kllznleasástni kössz jömssslmeni sát k 
] target ip [//d IE [bore ] protocol ] state ]l runid I 
e KK kuzázlzls aázáslzást atni láma zásást zta ezaz klzla ázzázlaea kell zza kezde 4 
I] 192.168.10.44 ] 2003-12-14 [ELOSO0OS 37 I 22. "e tep ] open ] 100 I 
] 192.168.10.44 ] 2003-12-14 [ELOSOOESZ I JEENNKEGp ] open ] 100 I 
] 192.168.10.44 ] 2003-12-14 [EOSOOSSZ I J3060NEGDI ] open ] 100 I 
] 192.168.10.44 ] 2003-12-14 [EELOSOOÉSZ I HO00KAlEEep ] open ] 100 I 
iga asdmááddi ius ata zlzizámtztsi FESS kezzel szad kemia aan ka 4 

4. lista A 192.168.10.44 cím eredményei egy két nappal később folytatott vizsgálat után 
in láda sagla aztan an jlzlassa atai tileaaatn k 
] target ip [doc [GE IBOGt ] protocol ] state ] 
tzsasssászimszai szt tázasszelm ttal ölni msg sss ate kk 
] 192.168.10.44 I] 2003-12-16 ] 00:47:16 I zi úda ] open I 
] 192.168.10.44 ] 2003-12-16 ] 00:47:16 I JA EKEGD ] open I 
] 192.168.10.44 ] 2003-12-16 ] 00:47:16 I SZOSNKEEED ] open I 
] 192.168.10.44 ] 2003-12-16 ] 00:47:16 I S000ENEEep ] open I 
kezelese ESZ zsszzz adag kae adta kiltát kzlla k 
Könnyen összehasonlíthatjuk a 4. és 5. lista eredményeités — mysal: select r.runid, r.d, r.t, t.ip, t.host, 


kiszűrhetjük a különbségeket. Természetesen a két adathal- 
maz összehasonlítását egy program is elvégezheti, amely 
összefoglalja számunkra a különbségeket. 

A korábban említett hoststat tábla minden működő gép 
információit tartalmazza. Az open ports oszlop egyszerű 
összegzést nyújt a nyitott kapuk számáról. Ahhoz, hogy 

a célgépünk nyitott kapujának egy soros információit meg- 
kapjuk, a következő lekérdezést kell futtatnunk: 


mysgl: select ip,d,t,open ports, ports scanned, 
-s runid from hoststats where order by ip, d, t; 


(Az order by záradékot a továbbfejlesztés érdekében írtuk 
a lekérdezéshez.) Az open ports oszlopot a date/time és 
runid oszlopokkal együtt vizsgálva vázlatos képet kapunk 
a nyitott kapuk állapotának egy biztonyos időn belüli válto- 
zásairól. A targets tábla az összes előforduló célgéppel kap- 


csolatos információt tartalmazza, IP-címenként egy-egy sort. 


Ez az egyetlen tábla, amelyben a gép neve (amennyiben 
meghatározható) és az Nap által feltételezett operációs 
rendszer tárolásra kerül. Nézzük, milyen információkat 
nyerhetünk a vizsgált címről: 


mysgl: select " from targets 
-5 where ip - "192.168.10.44 ; 


Láthatjuk, hogy az OS guessed mező tartalma jelen esetben 
Linux Kernel 2.4.0-2.5.20, a hostname (gépnév) oszlop 
pedig az ophelia.hasnains . com szöveget tartalmazza 
(szeretem Shakespeare tragikus hősnőit). Most, hogy már 
lényegében minden részlet a birtokunkban van, írjunk egy 
olyan lekérdezést, amely összegyűjtve tartalmazza a vizsgá- 
lat tárgyát képező gépre vonatközó összes adatot. 
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-5 t.os guessed, p.port, p.protocol, 
sp.service, 

-s5 p.state, p.fullversion from runlist r, 

-5 targets t, portstat p 

-5 where r.runid - 100 and p.target ip -— t.ip 

-s and p.runid — r.runid 

-s order by r.runid, r.d, r.t, t.ip; 

Helyszűke miatt nem mutatjuk meg a lekérdezés kimenet- 

ét, próbáljuk ki nyugodtan saját magunk. Használhatnánk 

jelentéskészítő programot is az eredmény célpontok szerin- 

ti csoportosításához. Ha tetszetősebb kimenetet szeretnénk, 

hatékonyabb fegyvereket kell bevetnünk, például a PHP 

vagy a Perl tehet megfelelő erre a célra. 

A jelentések közül az egyik leghasznosabb az egyes cél- 

pontok nyitott kapuinak változását szemléltető kimutatás. 

Vegyük például azt az esetet, amikor a vizsgált gépen be- 

záródott a 111/TCP kapu, de a 23/TCP nyitott állapotba 

került. Ebben az esetben a hoststats tábla open ports 

oszlopa még mindig négy kaput fog mutatni, pedig 

a részletekben változás következett be. A megfelelő prog- 

ram könnyedén kiválogathatja a különbsége(ke)t egy 

jelentés számára. 


Hasznos kimutatások 

Az alábbi, leggyakrabban használt lekérdezés arra a kér- 
désre ad választ, hogy egy bizonyos célpont esetén mely 
kapuk vannak nyitott állapotban: 


mysgl: select d, t, port, protocol, state, 
-s fullversion from portstat 
-5 where target ip -  "192.168.10.44" 
-s order by d,t,port; 
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5. lista Egy adott gépre vonatkozó összesített eredmények 


I os guessed 


4---- erett 4--- erett 4--- eres 44 errre 4 errre 
1 2003-12-14 ] 10:00:37 ] 192.168.10.44 ] ophelia.hasnains.com ] Linuxkernel 2.4.0 - 2.5.20 ] 
1 2003-12-14 ] 10:00:37 ] 192.168.10.44 ] ophelia.hasnains.com ] Linuxkernel 2.4.0 - 2.5.20 ] 111] tcp 
1 2003-12-14 ] 10:00:37 ] 192.168.10.44 ] ophelia.hasnains.com ] Linuxkernel 2.4.0 - 2.5.20 ] 3306 ] tcp 
1 2003-12-14 ] 10:00:37 ] 192.168.10.44 ] ophelia.hasnains.com ] Linuxkernel 2.4.0 - 2.5.20 ] 6000 ] tcp 
4---- rre 4--- erett 4--- ere 44 errre 4 


Egy másik gyakran használt kimutatás azt mutatja meg, hogy 
egy célgép bizonyos kapuja nyitva volt-e valamikor egy ko- 
rábbi időpontban: , Nyitva volt az SSH a 192.168.10.44 cí- 
men két héttel ezelőtt?" Feltéve, hogy az nmapsgl telepítve 
volt már és a crontab rendszeres időközönként le is futtatta, 

a válasz a következő lekérdezéssel kideríthető: 


mysgl: select d, t,target ip, port,protocol, 
-s5 service, state, fullversion from portstat 
-s5 where port - 22 and protocol - "tcp" 
-s5 and state — "open" 
-5 d - date sub( curdateO , interval 14 day) 
-5 order by d, runid, target ip ; 


Természetesen egy adott napon több nmapsg1 futtatásunk 
is lehet, emiatt szerepel az order by záradék. Ha az ered- 
ményhalmaz előállításához olyan más gyártótól származó 
eszközt használunk, mint a PHP vagy a Perl, a runlist táblá- 
ból kell a pontos időkerethez tartozó futásazonosítót meg- 
szereznünk és ezt felhasználva kell a kiválasztott célra vo- 
natkozó információkat lekérdeznünk. 

Egy másik hasznos lekérdezéssel egy adott hálózat azon 
célpontjait szűrhetjük ki, amelyek bizonyos kapuja nyitott 
állapotban van: , A 192.168.10/24 alhálózat hány gépén 
van nyitva a 80/TCP kapu?" A keresett eredményt a követ- 
kező lekérdezéssel kaphatjuk meg: 


mysgl:5 select runid, d, t, target ip, port, 
-s5 protocol, state from portstats 
-5 where port - 80 and protocol - 
-s and state — "open! 
-5 and target ip like "192.168.10.9 ; 


pép 


A szöveges megfeleltetés nem igazán alkalmas az alhálózat 
azonosítására, de a példa jól szemlélteti a megoldás lényegét. 


Különböző adatbázisok használata 

Számos esetben - például amikor egy szakértő több háló- 
zaton dolgozik felváltva — kívánatos, hogy meg tudjuk vál- 
toztatni az adatbázis nevét (ami esetleg lehet az ügyfelünk 
neve), így a különböző helyek adatai nem keveredhetnek 
össze egymással. A cikk írásának idején ezt úgy tehetjük 
meg, hogy módosítjuk az nmaplog által az adatbázis- 
tulajdonságok megadására szolgáló —/nmapsgl.rc fájl 
db-nmaplog bejegyzést. 

Az adatbázis menet közben való megváltoztatásához az 
-—/nmapsgl.rc fájlban lévő nmaplog helyére írjuk be a meg- 
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] port ] protocol ] service ] state ! fullversion I 


leedsi tasdedtdssegegsl jesdddesát uddsdte tdeddedttdásstttettásttle ! 


774 dada ] ssh I OpenssH 3.5p1 (protocol 1. 99) ! 
I 2 (rpc 4100000) l 
I MySOL4.0.16-standard-10g I 


I (access denied) I 


l open 
l rpcbind ] open 
l mysg1 
I xi 


I open 
I open 


tedd buzsdsdgsesgttegt ugdedte edd ezzdtggtsszetlsee elte! 


felelő nevet, és győződjünk meg arról, hogy a fájlban 
megadott felhasználó rendelkezik a megfelelő jogosultsá- 
gokkal az így beállított adatbázishoz. Ezután töltsük be az 
adatbázis-sémát az új adatbázisba. Ha az új adatbázis neve 
newnmap, akkor az alábbi egysoros paranccsal tölthetjük 
át a sémát: 


$ mysg] newnmap c nmaplog.sal 


Mégsem javaslom azonban a különböző adatbázisok hasz- 
nálatát, sokkal egyszerűbb az adatokat egy fájlba kimásolni 
és ezután az nmaplog adatbázisba egy üres sémát betölte- 
ni. A következő parancssorokkal hajthatjuk végre ezt 

a műveletet: 


$ mysgldump nmaplog 3 newnmap.sgi 
$ mysg] nmaplog c nmaplog.sal 


Az adatbázis-jogosultságok beállításától függően megeshet, 
hogy a parancsok fenti futtatásához létre kell hoznunk egy 
MySOL-felhasználót és jelszót. 


Alkalmazási módok 

Ha csak ritkán és néhány gépen alkalmazzuk az nmapsgl-t, 
nehezebben ismerhetőek fel a program hasznos tulajdonsá- 
gai. A program nagyobb környezetekben, több alhálózat és 
több tucatnyi vizsgálati célpont esetén mutatja meg az igazi 
tudását. A legegyszerűbb alkalmazási eset természetesen az, 
amikor az nmapsgl és a MySOL kiszolgáló ugyanazon a gé- 
pen helyezkedik el, ami lehet például egy hálózati szakértő 
hordozható gépe, amellyel hálózatról hálózatra jár. Mivel 

a legtöbb hálózat tűzfalas védelem alatt áll és RFC 1918-as 
címzést használ, egy hálózatok közt kóborló hordozható gé- 
pen lévő targets táblában nagy a valószínűsége, hogy egyes 
IP-címek többször is előfordulnak. Ebben az esetben tehát 
át kell töltenünk az adatainkat és minden új környezetnél 
friss adatbázissal kell dolgoznunk. 

Az nmapsgl-nek létezik más alkalmazási módja is: közepes 
méretű hálózatokban több pásztázó működhet a különböző 
alhálózatokban és a naplózásra használhatja ugyanazt 

a MYySOL kiszolgálót, vagy nagy hálózatokban, ahol több 
egygépes rendszer (a MySOL és az nmapsgl ugynazon a gé- 
pen fut) helyileg végzi a pásztázást és naplózást. Az ilyen 
rendszerekben kicsi az RFC 1918-as címek ketőződésének 

a valószínűsége. Igaz viszont, hogy a helyben történő pász- 
tázás és naplózás valamint a központi kiszolgálón történő 
adatgyűjtés közti időkülönbség miatt nem rendelkezünk 





Az nmaplog által használt táblák 





Az nmaplog adatbázisban jelenleg nyolc tábla található, 
amelyek közül a fontosabbak az alábbiak: 


e  TARGETS - a célgépről tartalmaz információkat, többek 
közt a célazonosítót, IP-címet, a gép nevét és az Nmap 
által feltételezett operációs rendszert. 


e — SCANNERS - az nmapsgl-t futtató gépről tartalmaz ada- 
tokat. A portstat táblához a scan id mezővel kap- 
csolódik. 


e  RUNLIST - a felhasználó azonosítóját, az Nmap indítá- 
sának dátumát és időpontját és a futtató gép informá- 
cióit tartalmazza. A felhasználó neve és azonosítója az 
/etc/passwd fájlból származik. A scanner. id mező 
a scanners.scan id mezőhöz kapcsolódik. 


e  PORTSTAT - a kapupásztázás eredményeit tartalmazza. 
rögzítésre kerül az összes nmaplog jelzett kapu az álla- 
potával (open/close/filtered, nyitott/zárt/szűrt) 
együtt. 


e — HOSTSSTAT - a célgép alapvető adatait, vagyis az 
nmapsal egyes futásainak időpontjaiban vizsgált 
összes, és az ebből nyitott állapotban lévő kapuk 
számát tartalmazza. 


ELLA 


azonnali adatokkal. Mindkét helyzetre igaz, hogy a pász- 
tázó-azonosító (scanner ID) jól használható az adatok 
szétválasztására. 


Fejlesztési irányok 

Gyakorló biztonsági szakértők - és el kell ismernem, néhány 
fekete kalapos számítógépes kalóz is — elismerik az nmapsgl 
képességeit, amely nagyfokú elvárások kielégítésére is alkal- 
massá teszik. A projekt jelenlegi fejlesztési céljai közt szere- 
pel, hogy a felhasználóknak lehetőségük legyen az nmapsgl 
beállításait közvetlenül az Nap felületén kersztül elvé- 
gezni, valamint egy olyan PHP-ben írt jelentéskészítő előtag 
létrehozása, amely megkíméli a végfelhasználót attól, hogy 
a lekérdezéseket a MySOL-be kelljen kézzel begépelnie. 
Ezek a kiegészítések pillanatnyilag fejlesztés alatt állnak. 

A távolabbi tervek közt szerepel a Nessus sebezhetőség- 
vizsgálati eredményének ugyanabba az adatbázisba történő 
befoglalása, s ezzel egységes kezelőpult létrehozása a kapu- 
pásztázás és sebezhetőségi értékelés eredményei számára. 
A cél felé vezető lépésként az nmapsg! honlapján találha- 
tunk egy egyszerű formai elemzőt, amely alkalmas a Nessus 
ügyféllel létrehozott fájlok betöltésére. 


Linux Journal 2004. október, 126. szám 


Hasnain Atigue (hatigueohasnains.com) a napos Szingapúr- 
ban él feleségével és három éves kislányával. Amikor lányá- 
val épp nem a Harry Pottert nézi, akkor próbál a hálózati 
gyűrűk ura lenni, ami néha sikerül is neki. 
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A Linux fájlrendszer biztonsága 2-2. rész) 


A múlt hónapban megismerkedtünk a jogosultságok alapjaival. Most itt az ideje, 
hogy megvizsgáljunk néhány hasznos bitet a felhasználók kényelmes és biztonsá- 
gos együttműködésének megteremtéséhez. 


últ alkalommal az alapoktól indulva vizsgáltuk 
HAt] meg a fájl- és könyvtárjogosultságok rendszerét: 

megismertük a felhasználók és csoportok fogal- 
mát valamint a fájlokra és könyvtárokra vonatkozó olvasási, 
írási és futtatási jogok beállításának és törlésének módját. 
Ebben a részben a jogosultságok néhány fejlettebb formájá- 
ra irányítjuk figyelmünket, felderítjük a jogosultságok nu- 
merikus módszerét, az umask parancsot és a root jogosultsá- 
gainak átadását a su és sudo parancsokkal. A mostani cikk 
a múlt havinál több középszintű információt tartalmaz, 
de remélhetőleg még akkor is érthető lesz, ha csak annyit 
tudunk a témáról, amit az előző alkalommal olvastunk. 


A sticky bit 

Idézzük fel a múlt hónapban tanulmányozott 
extreme casseroles könyvtár listájának eredményét: 
drwxr-x--- 8 biff drummers 288 Mar 25 01:38 
5 extreme. casseroles 


Biztosan emlékszünk még arra, hogy a könyvtárra vonatko- 
zó csoport-jogosultságokat r-x értékre állítottuk be, vagyis 

a csoport által olvasható és futtatható értékre, úgyhogy 

a drummers csoport tagjai beléphetnek ebbe a könyvtárba és 
olvashatják a benne található recepteket. Tegyük fel, hogy 
dobos barátunk, Biff, szeretné, ha zenésztársai nem csak 
olvasni tudnák ezeket a recepteket, hanem a sajátjaikat is 
elhelyezhetnék itt. Ahogy az elmúlt alkalommal láthattuk, 
ehhez nem kell mást tennie, mint beállítani a könyvtár cso- 
portra vonatkozó írási bitjét a következőképpen: 

chmod giw ./extreme casseroles 


Ezzel csak egy gond van: az írási jog magában foglalja az 
adott könyvtárban új fájl létrehozásának, illetve egy már lé- 
tező fájl törlésének a jogosultságát is. Mi akadályozza meg 
az egyik dobos cimborát abban, hogy mások receptjeit letö- 
rölje? A sticky bit, semmi más. 

Régebben a sticky bitet arra használták, hogy a fájlt (prog- 
ramot) a memóriába olvassanak be, így a hívása esetén sok- 
kal gyorsabban tudott betöltődni. A Linuxon azonban más 
a szerepe. Amikor egy könyvtár esetében beállítjuk a sticky 
bitet, akkor ezzel az adott könyvtárban korlátozzuk a fel- 
használók törlési lehetőségeit. Ez konkrétan azt jelenti, 
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hogy a könyvtárban egy adott fájl letörléséhez tulajdonosi 
jogokkal kell rendelkeznünk vagy a fájl vagy a könyvtár 
esetében, még akkor is, ha a tulajdonos csoporthoz tarto- 
zunk, és a csoport írási lehetősége be van állítva. 

A sticky bit beállításához az alábbi parancsot kell futtatnunk: 
chmod -4t könyvtárnév 


A példánkban a parancs formája chmod --t 

extreme. casseroles lenne. Ha most az 1s parancsot a -d 
kapcsolóval használva lekérdezzük magának a könyvtár- 
nak a részletes jellemzőit, hogy a könyvtárhoz kötődő jogo- 
sultságok jelenjenek meg és nem a könyvtár tartalma, 
vagyis kiadjuk a ls -Id extreme. casseroles parancsot, 

az alábbi eredményt kapjuk: 
drwxrwx--T 8 biff drummers 
5 extreme. casseroles 


288 Mar 25 01:38 


Figyeljük meg a jogosultságokat jelző karakterlánc végi T 
betűt. Normál esetben itt egy x vagy - jelet várnánk attól 
függően, hogy a könyvtáron az egyéb felhasználók rendel- 
keznek-e írási joggal. A T azt jelöli, hogy a könyvtáron az 
egyéb felhasználóknak nincs futtatási joga és a sticky bit be 
van kapcsolva. A korlátozás hatásának bemutatásához te- 
gyük fel, hogy az extreme casseroles könyvtár tartalmá- 
nak a kiíratása az 1. listán látható eredményt adja. 

Tegyük fel továbbá, hogy a crash nevű felhasználónak nem 
tetszik a pineapple mushroom surprise. txt fájl és ezért 
megpróbálja letörölni. Arra számít, hogy ez sikerülni is fog 
neki, hiszen a drummers csoporthoz tartozik, és a csoport 
rendelkezik ezen a fájlon írási joggal. Ne feledjük azonban, 
hogy biff bekapcsolta a szülőkönyvtár sticky bitjét. Ez az 
oka annak, hogy crash kísérlete kudarcba fullad, ahogy azt 
a 2. listán láthatjuk is. Még egy megjegyzés a sticky bittel 
kapcsolatban: a beállításnak csak az adott könyvtárszinten 
érvényesül a hatása. Talán észrevettük, hogy az 1. lista az 
extreme casseroles könyvtárban lévő két émelyítő recept 
mellett egy src nevű könyvtárat is tartalmaz. Az src könyv- 
tár tartalmára nem lesz hatással az extreme casserole 
sticky bitjének beállítása, habár magára a könyvtárra igen. 
Ha biff az src könyvtár tartalmát is meg szeretné óvni 

a csoport tagjai által végrehajtott törléstől, az src könyvtár 
saját sticky bitjét is be kell állítania. 














1. lista Az extreme casseroles könyvtár tartalma 


3 biff drummers 
3 biff drummers 
1 biff drummers 
1 biff drummers 


192 2004-08-10 23:39 . 

4008 2004-08-10 23:39 .. 
18 2004-07-0O8 07:40 chocolate turkey casserole.txt 
12 2004-08-0O8 15:10 pineapple mushroom surprise.txt 


drwxrwxr-T 
drwxr-xr-x 
-rw-rw-r-- 
-rw-rw-r-- 


drwxr-xr-x 2 biff drummers 


2. lista Törlési kísérlet a sticky bit bekapcsolt 
állapotában 


crash: rm pineapple mushroom surprise.txt 
rm: cannot remove 

5 "pineapple mushroom surprise.txt : 
Operation not permitted 


A setuid és setgid beállításai 

Elérkeztünk a LINIX világának legveszélyesebb jogosultság- 
bitjeihez, a setuid és setgid bitekhez. Egy futtatható bináris 
fájl esetén a setuid bit beállítása azt eredményezi, hogy 

a program a futtató felhasználótól függetlenül úgy fut, mint- 
ha a tulajdonosa futtatná. Hasonlóan, a setgid bitet beállítva 
egy futtatható fájl esetén az úgy fog futni, mintha a tulajdo- 
nos csoport tagja futtatná, függetlenül futtató személytől. 
Amikor azt a kifejezést használom, hogy úgy fut, azon azt ér- 
tem, hogy ugyanazokkal a jogosultságokkal fut a program. 
Tegyük fel, hogy biff megír és lefordít egy olyan ki1lpms 
nevű C programot, amelynek a hatása megegyezik az 

rm /extreme. casseroles/ 

5 pineapple mushroom surprise.txt 


parancséval, továbbá a 
chmod -s ./killpms 


paranccsal bekapcsolja a fájl setuid bitjét és beállítja a cso- 
port-futtathatóságát is. A killpms fájl részletes jellemzőit ki- 
íratva az alábbi sort láthatnánk: 
1 biff drummers 


-rwsr-xr-- 22 2004-08-11 23:01 


skillpms 


Ha crash lefuttatja ezt a programot, végül is sikerül elérnie, 
hogy törölje a Pineapple-Mushroom Surprise receptet — a 
killpms ugyanis olyan jogosultságokkal fut, mintha biff 
futtatta volna. Amikor a killpms megpróbálja letörölni 

a pineapple mushroom surprise. txt fájlt, sikerrel is jár, 
hiszen a fájl a tulajdonosa számára írható, a killpms pedig 
olyan jogosultságokkal rendelkezik, mint a tulajdonosa, biff. 
Ha egy programot a setuid bit beállításával akarunk futtat- 
ni, annak futtathatónak kell lennie a csoport és egyéb fel- 
használók számára — remélem nem kell magyaráznom, 
hogy miért. További jellemző, hogy a Linux rendszermagja 
a héjprogramok esetében nem veszi figyelembe a setuid és 
setgid biteket, ezek csak bináris (lefordított) futtatható fájlok 
esetében működnek. 

A setgid ugyanúgy működik, csak a csoport-jogosultságokat 
használja. Ha egy futtatható fájl esetén a chmod g-ts fi lenév 
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paranccsal beállítjuk a setgid bitet és a fájl futtatható az 
egyéb felhasználók számára (-r-xr-sr-x), akkor a fájl fut- 
tatásakor a csoportazonosítót (group ID) használja a futtató 
felhasználóé helyett. 

A fenti példa esetén, ha a killpms egyéb felhasználói jo- 
gosultságait r-x beállításra változtatjuk meg (chmod 0--x 
kil1pms), és ugyanakkor beállítjuk a setgid bitet is (chmod 
g9--s ki 11pms), akkor függetlenül attól, hogy ki futtatja 

a killpms-t az mindenképpen a drummers csoport jogosult- 
ságaival fog rendelkezni, hiszen a drummers a fájl csoport- 
tulajdonosa. 


A setgid és a könyvtárak 

De mi a helyzet a könyvtárakkal? Nos a setuid nincs hatás- 
sal a könyvtárakra, ellenben a setgid igen, ami nem teljesen 
magától értetődő tény. Rendes körülmények közt, ha létre- 
hozunk egy fájlt, annak tulajdonosaként önműködően a sa- 
ját felhasználói és (elsődleges) csoport-azonosítónk kerül 
beállításra. Például ha biff létrehoz egy fájlt, annak tulajdo- 
nosa biff lesz, a csoport-tulajdonosa pedig a drummers cso- 
port, amennyiben a drummers biff elsődleges csoportja az 
letc/passwd lista alapján. 

Beállítva azonban egy könyvtár setgid bitjét, az adott könyv- 
tárban létrehozott fájlok a könyvtár csoport-tulajdonosát fog- 
ják örökölni. Ez akkor hasznos, ha a rendszerünk felhaszná- 
lói jellemzően másodlagos csoportoknak is tagjai és rendsze- 
resen hoznak létre olyan fájlokat, amelyeknek e csoportok 
többi tagja számára is elérhetőknek kell lenniük. Például ha 
az animal nevű felhasználó az /etc/group fájlban úgy szere- 
pel, mint a drummers csoport másodlagos tagja, de az 
/etc/passwd listában az elsődleges csoportja a muppets, 
akkor animal minden gond nélkül létrehozhat az 

extreme casseroles/ könyvtárban fájlokat drwxrwx--T jo- 
gosultság-beállítással. Mivel alapértelmezésben anima! fájljai 
a muppets csoporthoz tartoznak, nem pedig a drummers cso- 
porthoz, a drummers csoport többi tagjának sem olvasási, sem 
írási joga nem lesz animal receptjein, amíg animal kézzel át 
nem állítja a fájljai csoport-tulajdonosát (chgrp drummers új- 
fájl) vagy meg nem változtatja az egyéb felhasználókra vo- 
natkozó jogosultságokat (chmod o--rw újfáj1). 

Másrészről viszont ha biff vagy a rendszergazda beállítja 

az extreme casseroles/ könyvtár setgid bitjét (chmod g--s 
extreme casseroles), akkor animal itt létrehozott új fájljai- 
nak csoport-tulajdonosa a drummers lesz a könyvtár tulajdo- 
nos csoportjának megfelelően. Minden egyéb jogosultság vál- 
tozatlan marad. Ha a kérdéses könyvtár már eleve nem írható 
a csoport által, akkor a setgid bitnek semmilyen hatása nincs, 
hiszen a csoporttagok nem hozhatnak benne létre fájlokat. 
Ezzel megismertük az összes jogosultsági lehetőséget: az 
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3. lista Az alapértelmezett jogosultságmaszkunk 
ellenőrzése 


mi ckalocalhost : /home/mick: umask 
0022 


setgid biteket. Ha mind a hatot megértettük, valószínűleg 
a Linux felhasználók kisebbik feléhez tartozunk. De ezzel 
még nincs vége! 


Numerikus módszerek 

Eddig kódokat használtunk a jogosultságok jelölésére: r je- 
lentette az olvasási jogot, w az írásit és így tovább. Monda- 
nom sem kell, hogy a minden mással együtt a rendszerünk 
a jogosultságokat is számokként tárolja. A chmod felismeri 
mind a kódokkal (Uu--rwx , go-w), mind pedig a számokkal 
megadott jogosultság-módosítókat. 

Egy számkód négy számjegyből áll, amelyek balról jobbra 
haladva a különleges jogokat, tulajdonosi jogokat, csoport- 
jogokat és az egyéb jogokat jelentik. Emlékezzünk rá, hogy 
az egyéb jogok azokra a felhasználókra vonatkoznak, akik 
nem tartoznak sem a tulajdonos, sem a csoporttagok kate- 
jogosultság, minden tulajdonosi jog be van kapcsolva, és 
semmilyen csoport- vagy egyéb jogosultság sincs. 

Minden jogosultság-típushoz egy meghatározott számérték 
tartozik, az egyes jogosultság-típusokhoz tartozó értékek 
pedig az egyes helyiértékeken összeadódnak: a számjegy az 
összes beállítani kíván bit összegét jelenti. Ha például a tu- 
lajdonosi jogosultságok értéke 7, ez a 4-nek (az olvasási jog 
értéke), a 2-nek (az írási jog értéke) és az 1-nek (a futtatási 
jog értéke) összegeként áll elő. 

Ahogy az előbb említettem, az egyes jogokhoz tartozó érté- 
kek: 4-olvasás, 2-írás és 1-futtatás. (Én úgy jegyeztem meg 
ezeket, hogy ismételgettem magamban az , olvasás-írás- 
futtatás, 4-2-17 mondókát.) Miért nem 3, kérdezhetné vala- 
ki? Azért, mert így biztosítható, hogy ne legyen két olyan 
jogosultság-kombináció, amihez ugyanaz az érték tartozik. 
A különleges jogosultságok a következők: 4 jelenti a setuid 
bitet, 2 a setgid bitet, az 1 pedig a sticky bitet. Például 

a 3000 a setgid és sticky bit bekapcsolását jelenti, miközben 
semmilyen más jogosultság nincs — ennek a beállításnak 
nincs persze sok értelme. 

Nézzünk még egy példát a numerikus megadásra. Ha futta- 
tom a chmod 0644 mycoolfile parancsot, az 1. ábrán látható 
jogosultságokat állítom be a mycoolfi e fájl számára. 

A numerikus módszer teljesebb leírását a coreuti1s pa- 
rancs Numeric Modes részében találhatjuk meg, vagyis ha 
kiadjuk az info coreutils numeric parancsot. 


Az umask parancs 

Mielőtt más témába kezdenék, szeretném bemutatni az 
utolsó jogosultsággal kapcsolatos parancsot. Az umask 

a Bash héjba beépített parancs, amely kiírja vagy beállítja 
az alapértelmezett jogosultságmaszkunkat. A sajátunkat az 
umask parancs paraméterek nélküli beírásával nézhetjük 
meg, ez egy négyjegyű számot fog eredményül adni. 

A rendszeremen a 2. listának megfelelő választ kaptam. 
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4. lista Egy 0022-es maszkkal létrehozott 
fájl és könyvtár 


-rwxr-xr-x 2 mick users 48 2004-08-13 08:31 default dir 


-rw-r--r-- 1 mick users 4 2004-08-13 08:31 default file 


A 0022 jelentése a következő: nincs különleges jogosultság, 
nincs tulajdonosi jogosultság, a csoport- és egyéb jogosult- 
ságok közül pedig az írási van bekapcsolva. Ez meg hogy 
lehetséges? 

A válasz, hogy valójában az umask nem a kóddal, hanem 
maszkokkal dolgozik. A 0022 az a szám, amit a 0777 érték- 
ből kivonva dönti el a rendszer, hogy a létrehozott fájlok- 
hoz milyen jogosultságokat rendel: 0777-0022 - 0755. 

Aha! Szóval a létrehozott fájljaim tulajdonosa rendelkezni 
port- és egyéb jogosultságok közül pedig az olvasás és fut- 
tatás lesz beállítva (5 — 4--1). Igaz ez? Majdnem. Valójá- 
ban az umask a futtatási jogosultságot önműködően csak 

a könyvtárakra állítja be. Még ha a jogosultság-maszkunk 
szerint szerepel is a futtatási jog, a létrehozott közönséges 
fájlok futtatás-bitje nem kerül önműködően bekapcsolásra. 
Tehát a 0022 jogosultságmaszkommal, amely az alapértel- 
mezett jogokat 0755 értékre állítja be, a default dir 
könyvtárban létrehozva egy default. file nevű fájlt, 

a két tételnek a részletes adatai a 4. listán lévő képet fog- 
ják mutatni. 

Az alapértelmezett jogosultságmaszkunk megváltoztatásá- 
hoz egyszerűen futtassuk az umask parancsot, paraméter- 
ként megadva a kívánt maszkot. Például ha azt szeretném, 
hogy az összes fájlom rendelkezzen csoport-olvasási joggal, 
de semmilyen más jogot nem szeretnék beállítani, ez a 0740 
numerikus kóddal fejezhető ki. Ezt kivonva a 0777 kódból 
a 0037 maszkot kapom, vagyis az alapértelmezett maszkom 
beállítására az umask 0037 parancsot kell használnom. Ez az 
új maszk azonban csak az aktuális munkafolyamattra és az 
ebből indított héjakra érvényes, ha álladósítani szeretném 

a beállítást, a .bashrc fájlomba új sorként be kellene írnom 
az umask 0037 parancsot. 


A su és sudo parancsok 

Most, hogy már mindent tudunk a jogosultságokról, nume- 
rikus kódokról és a maszkokról, szólnom kell néhány szót 
arról, hogy mi a helyzet a felhasználókkal, csoportokkal és 
ezek jogaival a gyakorlatban. A LINIX biztonsági rendszeré- 
vel nagyon gyakran az a gond, hogy egy adott rendszeren 
a hatókörök nagyjából úgy néznek ki, hogy a root mindent 
megtehet, a felhasználók meg szinte semmit. 

Sajnos sokkal könnyebb kiadni egy gyors su parancsot, és 
ezzel egy időre megszerezni a root-jogosultságokat, mint 
létrehozni egy jól meghatározott jogosultságokkal rendelke- 
ző csoportrendszert, amelyben a rendszergazdák és az al- 
rendszerek felügyelői pontosan azokkal a jogosultságokkal 
rendelkeznek, amelyekre szükségük van. Használhatjuk 
persze a su parancsot a -c kapcsolóval is, ami csak egy bi- 
zonyos parancs root-ként való futtatását teszi lehetővé az 
egész héj helyett (például su -c rm fájlnév. txt), de ehhez 
szükség van a root-jelszó beírására. Az pedig soha nem jó, 











Az ,egyéb" felhasználók olvashatják a fájlt: 
4 — olvasás 


A csoporttagok olvashatják a fájlt: 
— olvasás 


A tulajdonos olvashatja és írhatja a fájlt: 
6 — 4 (olvasás) -- 2 lírás) 


Semmilyen különleges tulajdonság nincs 
bekapcsolva 


1. ábra A mycoolfile jogosultságainak magyarázata 


ha néhány személyen kívül más is ismeri a root-jelszót. 

A root-mindent-visz probléma megoldásának egy másik 
megközelítési módja a SELinux-hoz hasonló szerep-alapú 
hozzáférési rendszer (RBAC) használata, amely olyan hoz- 
záférési rendszert léptet hatályba, ami csökkenti a root 
hatáskörét. Ez azonban talán még bonyolultabbá teszi 

a helyzetet, mint a megfelelő csoportok és csoport-jogosult- 
ságok beállítása, amivel nem akarom azt mondani, hogy 

a SELinux és társai ne lennének nagyon hasznosak - én 
nagyon szeretem az RBAC-t. 

Egy jó középutat jelenthet a sudo parancs használata. 

A sudo lehetővé teszi a felhasználók számára, hogy egyes 
parancsokat root jogosultsággal futtassanak anélkül, hogy 
ismerniük kellene a root-jelszót. A sudo mára a legtöbb 
Linux rendszercsomag alapelemét képezi. 

A sudo beállításait az /etc/sudoers fájl tartalmazza, de ennek 
közvetlen szerkesztésére nincs szükség. Ehelyett kiadhatjuk 
a visudo parancsot, amely megnyitja a fájl szerkesztőjét, 
ami alapesetben a vi. Az EDITOR környezeti változó meg- 
változtatásával más karakteres szerkesztőprogramot is beál- 
líthatunk. Például a /usr/bin/gedit használatához az alábbi 
parancsot kell kiadnunk: 

export EDITOR-/usr/bin/gedit 


Hely hiányában nem tudom részletezni a suwdoers fájl 
szerkezetét, a sudoers(5), sudo(8) és visudo(8) súgóoldala- 
kon olvashatjuk el a teljes leírást. Nézzünk inkább egy 
gyors példát. 

Emlékszünk még a crash felhasználó próbálkozására, hogy 
megszabaduljon a Pineapple-Mushroom Surprise 

recepttől? Bár ebben az esetben nem kellene ilyen durva 
eszközökhöz nyúlnunk - a bemutatott jogosultság-techni- 
kák megfelelő eszközt biztosítanak ehhez -, használhatjuk 
a sudo parancsot arra, hogy crash elérje célját, feltéve, 
hogy biff rendelkezik root-jogosultsággal. Először is vál- 
junk root felhasználóvá (su -). Ezután futtassuk a vi sudo 
parancsot. Ennek hatására a vi szerkesztőprogramba kerü- 
lünk, amelyben az /etc/sudoers fájl van épp megnyitva (ha 
a vi használatában újoncok vagyunk, a vi(1) súgóoldalt ér- 
demes elolvasnunk). Menjünk el a fájl végéig, majd adjuk 
az alábbi sort a fájlhoz: 
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crash localhost-/bin/rm /home/biff/ 
5 extreme casseroles/pineapple mushroom surprise.txt 


Mentsük a fájlt, majd lépjünk ki. Most crash a feladat 
elvégzéséhez beírja a következő parancsot: 

sudo rm /home/biff/extreme casseroles/ 

s pineapple mushroom surprise.txt 


A parancs a felhasználó jelszavának beírását kéri. Miután 
hibátlanul beírta, az alábbi parancs fut le, mégpedig root 
felhasználóként: 

/bin/rm /home/biff/extreme casseroles/ 

s pineapple mushroom surprise.txt 


Ezzel megtörtént a kérdéses fájl törlése. Egy másik megoldás, 
ha az /etc/sudoers fájlban lévő sor a következőképpen fest: 
crash localhost-/bin/rm /home/biff/ 

5 extreme casseroles/" 


Ebben az esetben crash bármit letörölhet az 

extreme casseroles könyvtárban függetlenül a sticky bit 
beállításától. 

A sudo nagyon kényelmes eszköz, de legalább ilyen ve- 
szélyes is lehet, bánjunk vele körültekintően — a root jo- 
gosultságaival nem szabad játszadozni. Tényleg okosabb, 
ha a felhasználói és csoportjogosultságokat állítjuk be 

a célnak megfelelően, mint ha kiadjuk a root jogosultságait, 
még ha csak a sudo parancson keresztül is. Még az is jobb, 
ha egy olyan RBAC-alapú rendszert használunk, mint 

a SELinux, amennyiben rendszer védelme ezt megkívánja. 
Ez alkalommal ennyi fért bele. Remélem hasznos volt ez 
az ismertető. Legyetek óvatosak a következő alkalomig! 
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Cikkgyújtés RSS használatával 


A hírgyűjtő rendszerek nem csak weblogok figyelemmel kísérésére alkalmasak. 
Az RSS segítségével a látogatókat könnyen tájékoztathatjuk egy-egy webhely 


vagy alkalmazás változásairól is. 


mikor elkezdtem használni a webet, még az volt 
A a szokás, hogy minden új weboldal fenntartója 

küldött egy levelet Tim Berners-Leenek, amiben 
megadta az LIRL-t és az oldal témájának rövid leírását. Tim 
válaszában röviden összefoglalta személyes megjegyzéseit, 
majd frissítette a weboldalakat tartalmazó főlistát, amit bár- 
ki szabadon megnézhetett. A webes közösség aktív résztve- 
vői rendszeresen átnézték a listát — majd utódját is, amelyet 
mellesleg a Mosaic böngésző készítői állítottak össze -—, és 
kimazsolázták belőle az új vagy frissített oldalakat, nehogy 
lemaradjanak valami érdekesről. 
A web alig egy évtized alatt túl nagyra nőtt ahhoz, hogy 
az új webhelyek listáját kézi munkával fenn lehetne tarta- 
ni. Még ha találnánk is rá embereket, a látogatók csak egy 
kis töredékét tudnák befogadni a minden egyes nap nyil- 
vánosságra kerülő új tartalomnak. Ha figyelembe vesszük, 
hogy napjainkban már több százezer weblog, röviden blog 
üzemel, és sokat közülük elég gyakran frissítenek, akkor 
nyilvánvalóvá válik, hogy a feladat rendkívül nehezen 
oldható meg. 
Az egyik megoldás, hogy böngészőnkben könyvjelzőket 
használunk, ám ezek rendszeres végiglátogatása rendkívül 
vesződséges, főleg, ha naponta többször kívánjuk elvégez- 
ni. Milyen jó lenne, ha mindegyik oldal maga jelezné válto- 
zásait, így csak akkor kellene meglátogatnunk őket, amikor 
valóban érdemes! 
Az ötlet persze nem új, a tartalmukat hirdető weboldalak 
elképzelése már évekkel ezelőtt megszületett. Sajnos be kell 
vallanom, csak néhány hónappal ezelőtt jöttem rá, hogy 
mennyire elmaradott módszert alkalmazok, amikor könyv- 
jelzők alapján látogatom végig a kedvenc oldalaimat. Egy 
RSS összesítő segítségével — vagyis egy olyan programmal, 
amely összegyűjti a különféle helyek RSS cikkeit, és jelzi, 
ha valahol frissítettek — mindezt sokkal kevesebb idő alatt 
el tudom végezni. 
Ebben a hónapban a népszerű RSS (Really Simple 
Syndication; valóban egyszerű cikkgyűjtés) vagy RDF 
Site Summary (RDF webhely-összegzés) formátumcsaládot 
tárgyaljuk, megvizsgáljuk, hogy tagjai milyen célokra 
használhatók, illetve a szabványoknak megfelelő cikkek 
hogyan állíthatók elő. 
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Egyszerű RSS 

Az RSS tulajdonképpen a Netscape gyermekének mondha- 
tó — az internetes céget azóta az AOL felvásárolta, gyakorla- 
tilag eltüntette. A Netscape ötlete az volt, hogy a felhaszná- 
lóknak több forrásból származó híreket kínál egyetlen olda- 
lon. Ebből a célból született meg az RSS 0.90. Aki a Netscape 
portálján keresztül híreket szeretett volna közzétenni, RSS 
segítségével tehette ezt meg. A Netscape rendszere lekérte 

a megfelelő RSS dokumentumot a kérdéses webhelyról, 
majd közzétette a kapott anyagot. 

Bár az RSS 0.90 kisebb forradalmat indított el, rendkívül bo- 
nyolult volt. Dave Winer, a Userland Software későbbi veze- 
tője az RSS-t sokkal egyszerűbb szabálygyűjteménnyé dol- 
gozta át, nevét RSS 0.91-re változtatta, majd elkezdte saját 
weblogjában, a scripting.com oldalon népszerűsíteni. 

Az RSS 0.91 szinte azonnal megjelent a web összes szegleté- 
ben, és Dave narancsszínű XML gombjai, amelyek az egyes 
helyek RSS-képességét jelezték, hatalmas népszerűségre 
tettek szert. Néhány év alatt további RSS-változatok is meg- 
jelentek. Az RSS 1.0 fejlesztését egy webes csoportosulás 
végezte, míg az RSS 2.0 — Dave vezényletével — a 0.9x to- 
vábbfejlesztéseként jelent meg. 

Aki jól figyelt, észrevette, hogy jelenleg három különböző, 
ám egyaránt RSS-nek nevezett cikkgyűjtő formátum is léte- 
zik. Bár vannak közöttük hasonlóságok, a különféle válto- 
zatok erősen eltérő formátumokat adnak meg. 

Az RSS sok tekintetben hasonlít a HIML-re és a HITP-re, 

és eleinte egy kisebb csoport által fejlesztett, könnyen meg- 
érthető és könnyen megvalósítható szabványról volt szó. 

Az elmúlt évek során azonban mindhárom szabvány hatal- 
mas fejlődésen ment keresztül, ami rugalmasságuk és egy- 
szerűségük részleges elvesztéséhez vezetett. 

A legegyszerűbb - és nem kevéssé népszerű - változat az 
RSS 0.91. Minden tartalmat crss:z címkék közé kell helyez- 
ni, ez tartalmazza a változat megjelölését, és egy darab 
cchannel: (csatorna) elem szerepelhet benne. A kötelező 
címkéket title, link, description, language és image 
(rendre cím, hivatkozás, leírás, nyelv és kép) egy vagy több 
citems: (tétel) elem követi. Minden tétel saját címmel, hivat- 
kozással és leírással rendelkezik. Példaként lássunk egy 
egyszerű RSS-cikket saját weblogomból (1. lista). 














Ha megvizsgáljuk a fenti RSS-cikket, láthatjuk, hogy a ko- 
rábban említett RSS 0.91 szabálygyűjtemény előírásainak 
nem felel meg, ugyanis hiányzik belőle a kötelező nyelv 

és kép elem, illetve nem mindegyik tételhez tartozik leírás. 
Rutinosabbaknak ez aligha okoz meglepetést, régebben 

a HTML esetében is láthattunk ilyesmit: a programok készí- 
tői megelégednek olyan kimenet előállításával, amely hiá- 
nyos ugyan, ám az alkalmazási területek túlnyomó részén 
megállja a helyét. Ezt a divatot követi a COREBlog is (jelen- 
leg ezt használom saját weblogom készítéséhez), segítségé- 
vel használható, ám az RSS 0.91-nek csak részben megfelelő 
cikkeket állíthatunk elő. 


A cikkek létrehozása 

Ha szabványos RSS-cikket szeretnénk előállítani, próbál- 
kozzunk meg a népszerűbb nyelvek mindegyikéhez elérhe- 
tő nyílt forrású modulok valamelyikével. A Perl-hívők szá- 
mára például az XML : :RSS modul jelent segítséget, ezt bár- 
melyik CPAN tükörről le lehet tölteni (lásd az internetes 
források részt). 

Ha a modul segítségével RSS-cikket szeretnénk létrehozni, 
az alábbihoz hasonló egyszerű programot kell írnunk. 


$1!/usr/bin/per1 
use strict; 
use diagnostics; 


use warnings; 


use XML::RSS; 
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my $url - "http://altneuland.lerner.co.i1/7; 
my $rss - new XML::RSS (version —s "0.91 ); 
$rss-schannel(title  -5 "Altneuland , 
Tink s $url, 
language — "en, 
description -s "Reuven Lerner s 
5 weblog"); 


$rss-sadd item(title 
Tink 
description 


); 


—s "Being scared, 
s "$ur1l/43/index htmW", 
-5 "Blog entry" 


print $rss-sas string; 


A program első lépéseként egy új XML : :RSS objektumot 
hozunk létre, egyúttal azt is kinyilvánítjuk, hogy az 
RSS szabvány 0.91-es változatát kívánjuk használni. 
Ezután az egyedi tételeket adjuk meg. Az image címkét 
elhagyhatjuk. Bár az XML : : RSS modul a csatorna leírásá- 
ból bármelyik címke elhagyását lehetővé teszi, például 
a cím és a hivatkozás kihagyásával az egész cikk értel- 
mét veszti. 

Következő lépésünk a csatorna feltöltése az egyes tételek- 
kel. Amikor ezzel végeztünk, készen állunk az RSS kimenet 
előállítására, amely a következőképpen fog alakulni: 


c?xm] version-"1.07" encoding-"UTF-8"?s 


S,IDOCTYPE rss PUBLIC 

5 //Netscape Communications//DTD RSS 0.91//EN" 
"http: //my . netscape . com/publish/formats/rss- 
0.91.dtd"5 


arss version-"0.9175 


cchannels 

ctitlesAáAltneulandc/titles 

clinkszhttp://altneuland. lerner.co.i1/c/Tinkz 
cadescriptionsReuven Lerner/s weblog c/descriptionz 
clanguageszenc/languages 


citemz 

ctitlesBeing scaredc/titles 
clinkszhttp://altneuland. lerner.co.i1/43/index html 
5 e/Vinksz 

adescriptions:Blog entryc/descriptionz 

c/itemz 


c/channels 
ce/rssz 


Az RSS-cikkek előállítására szolgáló programok nagy része 
nem fogja ismételten meghívni az $rss-sadd itemO függ- 
vényt, ahogy én tettem. Ha weblog, kereskedelmi hírlap 
vagy egyéb gyakran frissített oldal változásait szeretnénk 
jelezni, akkor célszerűbb egy olyan RSS-cikket készítenünk, 
amely egy könyvtár fájljain vagy — még jobb megoldás — 
egy relációs adatbázis sorain halad végig újra és újra. 
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Az alábbi kódrészlet például az utolsó 24 órában megjelent 
weblog bejegyzéseket gyűjti össze egy PostgreSOL alatti, 
weblog entries nevű táblába. 


f Az összes az utolsó 24 órában készült bejegyzés 
ft kigyűjtése 
my $sg] - "SELECT entry id, title, link, 
description 
FROM weblog entries 
WHERE when entered 5- (NOWO - interval 
571 day)"; 


$ Az SOL-utasítás összeállítása 
my $sth - $dbh-sprepare($sa1); 


f AZ SOL-utasítás végrehajtása 
my $result - $sth-sexecute; 


ft végiglépkedés a kapott sorokon 

while (my $rowref - $sth-sfetchrow arrayref) 

1 

my ($id, $title, $link, $description) - G$rowref; 


$rss-sadd item(title -—5 $title, 
Tink -—5 $Tlink, 
description -5 $description 


35 


A fentiekből azonnal nyilvánvalóvá válik az is, hogy miért 
érdemes relációs adatbázisban tárolni a weblogokat. Ha 

a bejegyzések bekerülnek valamilyen adatbázisba, az új 
szolgáltatások, például a cikkgyűjtés megvalósítása már 
egyszerű. Noha az XML : : RSS biztosít lehetőséget a be- 
gyűjtött cikkek számának korlátozására (erre példakódot 
is találunk), erre a feladatra az adatbázisok sokkal al- 
kalmasabbaknak tűnnek, hiszen esetükben egyszerűen 

a LIMIT módosítóval be tudjuk állítani a kapott sorok 
számának felső határát. 


Attérés az RS5 1.0 változatra 

Az RSS 1.0 egyfajta válasz volt az RSS 0.91-re, célja a közelí- 
tés volt a World Wide Web Consortium (W3C) különféle 
szabványaihoz, többek közt az RDF-hez. A változatszám 
alapján azt hihetnénk, hogy az 1.0 a 0.91 frissítése, ám a je- 
lölés rendkívül szerencsétlen, hiszen két teljesen független 
megoldásról van szó. A 0.91 (és utódja, az RSS 2.0) fejleszté- 
sét a közösség visszajelzései alapján Dave Winer végezte, az 
1.0 változat viszont fejlesztők egy nyitott közösségének 
munkája nyomán állt elő. Az RSS 0.91 és 2.0 között több ha- 
sonlóságot fedezhetünk fel, mint az 1.0 és a másik két válto- 
zat bármelyike között, ami nem meglepő módon számos 
félreértés forrása. 

Az RDF (Resource Development Framework, erőforrás- 
fejlesztési keretrendszer) a W3C fejlesztése, a szemantikai, 
jelentéstani web létrehozására irányuló tervezet része, 
amelynek célja az, hogy a webet az embereken túl a számí- 
tógépek számára is érthetővé tegye. Ehhez alapfeltétel 

a metaadatok, vagyis a webhelyek által átadott anyagokat 
kísérő, a felhasználók számára láthatatlan leírók szabványo- 
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2. lista 


my $rss - new XML::RSS (version —5 (1.00); 

A módosítást követően a létrejövő RSS-cikk picit 
eltérően épül majd fel. 

c?xml] version-"1.07 encoding-"UTF-8"?3 


ardf:RDF 
xmins : rdf-"http : //ww.w3 . org/1999/02/ 
5 22-rdf-syntax-nst" 
xminsz NEtpEZZPpUtülÉosg/tsszlő0ze 


xmiIns : taxo- "http: //pur1 . org/rss/1.0/modules/ 
5 taxonomy/" 
xmilns:dc-"http://pur1 . org/dc/elements/1.1/" 


xmilns : syn-"http: //pur1 . org/rss/1.0/modules/ 
5 syndication/" 
xmiIns : admin-"http: //webns . net/mvcb/" 
ba 


cchannel 
rdf:about-"http://altneuland. lerner.co.i1/75 
ctitlesAltneulandc/titles 
clinkzhttp://altneuland. lerner.co.i1/c/Tinkz 
cadescriptionsReuven Lerner s weblog 
c/descriptionz 
cdc: languagezenc/dc: languages 
citemsz 
crdf:Segz 
zndd slastdt s Fesouree—- 
"http: //altneuland. lerner.co.i1/ 
9 43/index html" /5 
c/rdf:Segz 
ca/itemsz 
ca/channels 


citem rdf:about- 

"http://altneuland. lerner.co.i1/43/index html"5 
ctitlesBeing scaredc/titles 
clinkzhttp://altneuland. lerner.co.i1/43/ 

sindex htmlc/Tinkz 
cdescriptionsBlog entryc/descriptionz 
ca/itemz 


c/rdf:RDF3 


sítása. Az RDF is egy próbálkozás erre a szabványosításra. 
Az RSS 1.0 tehát a cikkgyűjtést az RDF-hez csatolja, gon- 
doskodva az XML névterek használatáról is. Az XML név- 
terek segítségével különböző XML-megadásokat is össze 
tudunk fogni egyetlen dokumentumba. 

Ha az RSS 1.0-nak megfelelő cikket szeretnénk összeállítani, 
akkor a fenti programban egyetlen apró módosítást kell 
végrehajtanunk, mégpedig át kell írnunk az XML : :RSS ese- 
tében megjelölt változatszámot. Lásd az 1. listát. 








3. lista 
c?xm] version-"1.0" encoding-"UTF-8"?s 


crss version-"2.07 
xmlns :blogchanne1-"http: //backend. userland . com/ 
s blogchannelModule"s 


cchannels 

ctitlesAltneulandc/titles 
clinkszhttp://altneuland. lerner.co.i1/c/Tinkz 
cadescriptionsReuven Lerner" s weblog 
c/descriptions 

clanguagezenc/languagez 


citemz 

ctitlesBeing scaredc/titlez 

clinkszhttp://altneuland. lerner.co.i1/43/ 
s index htmlc/Tinkz 

cdescriptions:Blog entryc/descriptionz 

c/itemz 


c/channels 
SIESS 


A kimenetben több említésre méltó elem is található. Érde- 
mes például észrevenni, hogy benne számos névteret 
adunk meg és használunk, ezek bevezetése az xmiIns jel- 
lemzőkkel történik, de további, kifejezetten az RDF-hez 
kötődő jellemzőket is használunk, mint az rdf : about és 
az rdf: resource. 

A fentiekben az RSS 1.0 által kínált lehetőségeket lé- 
nyegében kihasználatlanul hagyjuk, hiszen a szabvány 
nagy számú beállítás megadására kínál módot. Például, 
az $rss-:channel O híváshoz egy syn részt adva beállít- 
hatjuk oldalunk cikkgyűjtési frissítésének gyakoriságát. 
Az RSS 1.0 a Dublin Core-t is támogatja, ez egy folyamato- 
san növekvő népszerűségű szabványos megoldás a doku- 
mentumok címkézésére. 


RSS 2.0 

A jó hír az, hogy - amint láttuk — az RSS 1.0 formátumú 
cikkek előállítása vagy feldolgozása nem különösebben 
nehezebb, mint az RSS 0.91 formátumúaké, feltéve persze, 
hogy naprakész eszközökkel rendelkezünk. Csakhogy az 
RSS 1.0 viszonylag bonyolult, néhányan úgy vélik, hogy 
túlzottan is. 

Mivel a számos próbálkozás ellenére nem sikerült meg- 
egyezésre jutni az RSS 1.0 tekintetében, fejlesztők egy 
csoportja Atom név alatt új tervezetet indított. Az Atomról 
most nem szólnék, azt viszont érdemes tudni róla, hogy 
felbukkanása ösztönözte a Winer által vezetett RSS tábort 
az RSS 2.0 kifejlesztésére. 

Ha RSS 2.0-megfelelő cikkeket szeretnénk előállítani, akkor 
újfent a kívánt változatszámot kell módosítanunk: 


my $rss - new XML::RSS (version —s 2.0); 
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Ügyeljünk arra, hogy a változatszám 2.0; nem 2 és nem 
2.00. Utóbbiak egyike sem fog működni, a változatszám 
ellenőrzése ugyanis karakterláncok összevetésével és nem 
számértékek összehasonlításával történik. Hogyan néz ki 
az RSS 2.0? Nem fog túl sok meglepetést okozni (3. lista). 
Amit fent látunk, nagyon hasonlít a 0.91-es RSS-re, de akár 
az RSS 1.0 lecsupaszított változatának is tekinthető. Ha vi- 
szont felidézzük azt a tényt, hogy az RSS 2.0 a 0.91 utódja, 
melynek feladata — a kis méret, az egyszerű megvalósítha- 
tóság és rugalmasság megőrzése mellett — a felmerült hiá- 
nyosságok pótlása volt, azonnal minden megvilágosodik. 
Az RSS 2.0 számos fejlesztést hordoz magában a 0.91-hez 
képest, a legfontosabb talán a névterek modulokként való 
használata, amivel új szolgáltatások valósíthatók meg. 

Az RSS 2.0 által megadott vagy használt névterek szá- 

ma messze nem közelíti meg az 1.0-nál látottat, ám en- 

nek fő oka az, hogy nem próbálkozik meg az RDF meg- 
valósításával. 

Winer részben a RSS 2.0 szabálygyűjtemény szerzői jogának 
megtartása miatt őt ért kritikák hatására a jogokat a Har- 
vard Universitynek adta át. Feltételezhető, hogy Winer to- 
vábbra is fontos szerepet fog játszani az RSS 2.0 fejlesztésé- 
ben, ám nem ő lesz az, aki végső soron dönt a használattal 
vagy a bővítésekkel kapcsolatos kérdésekben. 

A szétválás mindettől függetlenül véglegesnek tűnik. Kiala- 
kult egy Atom csoport és egy RSS csoport, én nem nagyon 
hiszem, hogy valaha is közös nevezőre jutnak. A fejlesztői 
táborok által kitűzött célokat szemlélve ez a legkevésbé 
sem meglepő - végül is nem várhatjuk el, hogy ugyanaz 

a szabálygyűjtemény egyszerre törekedjen az egyszerűség- 
re és a rugalmasságra. 


Osszefoglalás 

Ez alkalommal az RSS jelenleg is használatban lévő változa- 
tait tekintettük át, illetve összevetettük stílusukat és fejlesz- 
tőik célkitűzéseit. Szerencsére, ha valaki szeretne egyszerű, 
begyűjtésre alkalmas cikkeket készíteni, különösebb nehéz- 
ségekre nem kell számítania. Bár a programozók az egyes 
változatokra egyedileg jellemző mezőket is hozzáadhatnak, 
az alap mindegyik RSS-változatnál azonos, függetlenül at- 
tól, hogy az együttműködésnek még a szándéka is hiány- 
zik. A létrejövő RSS-cikkek természetesen egészen eltérő 
kinézetűek is lehetnek, függően a kiválasztott változattól. 
Következő írásomban az RSS nemrég megjelent, ám egyre 
elterjedtebb vetélytársáról, az Atom cikkgyűjtő formátumról 
lesz szó. Ha azzal is végeztünk, akkor áttekintjük, hogyan 
készíthetünk saját cikkgyűjtőt, amellyel különböző forrá- 
sokból származó cikkeket tudunk értelmezni és kezelni. 
Megvizsgáljuk az RSS használatának különféle módjait is, 
illetve azt, hogy a cikkgyűjtők révén hogyan juthatunk 
hozzá a legfrissebb hírekhez és a legújabb véleményekhez. 


Linux Journal 2004. október, 126. szám 


Reuwven M. Lerner (5 http:/Avww.lerner.co.il/atf) 
Nyílt forrású programokra, valamint web- és adat- 
bázis-alkalmazásokra szakosodott tanácsadó. 
Könyve, a Core Perl, 2002 januárjában jelent meg 
a Prentice Hall gondozásában. Reuven feleségével 
és lányaival nemrég költözött Chicagóba. 
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Tudományos célú képalkotás a POV-Ray 


segítségével 


Egy kis munkával a Persistence of Vision Raytracer (POV-Ray) felhasználható 
arra, hogy lebegőpontos tudományos adatfájlok alapján lélegzetelállító 


háromdimenziós ábrákat hozzunk létre. 


eteorológus vagyok a Michigani Központi Egye- 
JI temen, ahol az Illinois Egyetemen dolgozó kollé- 

gáimmal a szupercellás zivatarok viselkedését 
kutatom. Ezek a hosszú életű örvénylő szörnyetegek min- 
den tavasszal nagy felfordulást okoznak a Nagy Síkságokon 
az Egyesült Államokban. E félelmetes viharok tanulmányo- 
zásának elsődleges eszköze számomra egy NCOMMAS ne- 
vű numerikus modell, egy FORTRAN 90 nyelven írt számí- 
tógépes program, amely a fizikai egyenletek felhasználásá- 
val emulálja a légkör háromdimenziós időbeli állapotválto- 
zását. Ez a modell egy négy órás vihar szimulációja során 
roppant mennyiségű adatot állít elő, amely még vesztesé- 
ges tömörítéssel is 200 GB nagyságrendű marad. A kutatá- 
saim során felmerült egyik nagy kihívás az volt, hogy mó- 
dot találjak ezeknek az adatoknak olyan tudományos igé- 
nyű megjelenítésére, amellyel betekintést nyerhetnénk 
a szimulált vihar fizikai természetébe. 
A háromdimenziós adatok megjelenítésének egyik módja 
egy sugárkövető (raytracer) használata. A sugárkövető egy 
olyan számítógépes program, amely a pontkép előállításá- 
hoz a fény viselkedését szimulálja, amint az a háromdimen- 
ziós térben elhelyezett virtuális tárgyakkal kölcsönhatásba 
lép (1. ábra). Az így kapott bittérkép megjeleníthető ezután 
a számítógép képernyőjén, vagy lemezre menthető valami- 
lyen ismert formátumban, mint amilyen a PPM vagy 
a TIFF. A Persistence of Vision Raytracer, vagy röviden POV- 
Ray egy népszerű nyílt forráskódú sugárkövető program, 
amely akkor keltette fel az érdeklődésemet, amikor a 90-es 
évek közepén a Wisconsin Egyetemen a doktori disszertáció- 
mat írtam. Abban az időben konvektív leáramlások — a vi- 
harfelhőkben időnként kialakuló lefelé irányuló légáramlás- 
ok - háromdimenziós adatainak megjelenítésére kerestem 
megfelelő programot. Mivel a tudományos életben hozzá 
voltam szokva a megosztott forráskódokhoz és végzős di- 
ákként anyagilag sem álltam jól, olyan ingyenes és forrás- 
kódban terjesztett programot kerestem, amit letölthetek és 
különleges igényeimhez igazíthatok. A logikus választás ak- 
kor a POV-Ray volt és ma is megfelel az igényeimnek, ami- 
kor a kutatásaim adatait sugárkövetési módszerrel előállí- 
tott képen szeretném megjeleníteni. 
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A tudományos adatok leképezése nem az a feladat, amelyre 
a POV-Ray eredetileg készült, és kevés kutató használja 

a programot erre a célra. Más sugárkövető programcsoma- 
gok a numerikus modellek terén jobban támogatják a kuta- 
tók munkáját, de ezek zárt forráskódúak és meglehetősen 
drágák. Ebben a cikkben körvonalazom azt a módszert, 
amellyel a POV-Ray képessé tehető a háromdimenziós tudo- 
mányos adatok szintfelületeinek közvetlen megjelenítésére. 


A forráskód megszerzése 

Bár a POV-Ray bináris változatban is elérhető Linux, Mac 
OS és Microsoft Windows operációs rendszerekhez, nekünk 
szükségünk lesz a forráskódra is ahhoz, hogy a foltokat 
alkalmazni tudjuk, és további módosításokat hajthassunk 
végre. A cikkben az írás idején elérhető legfrissebb, 3.5 vál- 
tozatot használom. A POV-Ray letöltési oldalán választa- 
nunk kell a Unix, Linux és általános forráskód közül, és 
meg kell szereznünk Ryouichi Suzuki Density File kiterjesz- 
tés-foltját (lásd a hálózaton elérhető címek között). 

Ez egy Zip fájl, amely a POV-Ray fájljainak egy részét 
helyettesítő forráskódot tartalmaz. A pov35dfjs.zip fájlt 

a povray-3.50c/src könyvtárban kell kicsomagolni, ahol 
felül fog írni tizenhárom fájlt. 


A jelenetek és a szintfelületek 

A POV-Ray olyan jelenetleíró fájlokkal dolgozik, amelyek 
minden információt tartalmaznak a bittérképes kép létreho- 
zásához. A POV-Ray saját, a honlapján jól dokumentált jele- 
netleíró nyelvet használ. Ha korábban nem használtunk 
semmilyen sugárkövető programot, azt javaslom, hogy is- 
merkedjünk meg a módszer alapjaival és a POV-Ray jelenet- 
leíró fájljaival, még mielőtt a forráskódhoz hozzányúlnánk. 
A POV-Ray-ben leképezett elemeket objektumoknak nevez- 
zük, amelyekre példa a téglatest, gömb, tórusz vagy a sík. 

A felhasználó megadja az objektum jelenetben elfoglalt he- 
lyét, a méreteit, színeit, megvilágítási jellemzőkét és így to- 
vább. Ezek az adatok egy jelenetleíró fájlban szerepelnek, 
amelyeket a .pov kiterjesztésük miatt esetenként pov-fájlok- 
nak is neveznek. A jelenetleíró fájlok közönséges szövegfáj- 
lok, amelyek értelmezését a POV-Ray futásidőben végzi el. 

















1. ábra Egy teljes szupercellás vihar légi felvétele körülbelül 30 kilométeres távolságból a POV-Ray segítségével leképezve 


Egy általánosan használható objektum a szintfelület. 

Ez egy olyan háromdimenziós forma, amelynek a felüle- 
te az azonos függvényértékkel rendelkező pontok megje- 
lenítésével áll elő. A függvény állandó értékét a felhasz- 
náló választhatja ki. A POV-Ray számos olyan előre defi- 
niált objektumot tartalmaz, amely valójában szintfelület- 
nek is tekinthető. A következő jelenetleíró fájlból szár- 
mazó részlet például egy 0,7 egység sugarú, szürke szí- 
nű gömböt képez le, melynek középpontja az origóban, 
vagyis a (0,0,0) Descartes-koordinátákkal jellemzett 
pontban helyezkedik el: 


sphere 
í 
20,0,03, 0.7 
pigment (£ rgb .53 
3 


Ugyanez az objektum szintfelületként is megadható lenne 
az alábbi módon: 


fdeclare R — 0.7 

isosurface 

Tt 
function ( xx 4 yry 4 z"z - R"R) 
pigment (£ rgb .53 

3 


A meghatározás hátterében az áll, hogy az R sugarú gömb 
az alábbi matematikai egyenlettel írható le: 


Xx4yYy4áZzZ-R-0 


A szintfelületeknek ez a sokoldalúsága volt az a tulajdon- 
ság, ami miatt ezt az objektumot választottam a zivatarok 
ábrázolásához. 


Sűrűségfájlok 

A gömb példájában egy matematikai függvényt használtam 
a szintfelület értékének kiszámításához. A zivatarjaimhoz 
használt numerikus modell adatai nem írhatók fel egyetlen 
matematikai függvényként, ehelyett egy olyan háromdi- 
menziós lebegőpontos tömbökről van szó, amelyek minden 
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rácspontban valamilyen modellváltozót tartalmaznak, ami 
például lehet hőmérséklet, szélsebesség vagy felhősűrűség 
(2. ábra). 

A POV-Ray 3.5 változatának van egy sűrűségfájl nevű 
szolgáltatása, amely lehetővé teszi a függvények rács- 
pont-értékekként való leképezését. A POV-Ray doku- 
mentációja a következőképpen írja le a sűrűségfájlokat: 
"A sűrűségfájl-mintázat egy olyan háromdimenziós bit- 
térkép-mintázat, amely egy €0,0,0£ és c1,1,15 koordiná- 
tájú pontok között elhelyezkedő egységnyi kockát tölt be. 
Az adatfájl egy a POV-Ray számára készült, dfő nevű 
nyers bináris fájlformátum." 

A sűrűségfájlok olyan függvényként használhatóak, 
amelyeket a szintfelület-objektum paraméterként kap 

meg. Íme egy példa a szintfelület leképezéséhez használt 
sűrűségfájlra: 


fdeclare DENSFUNC-function 


( 
pattern 
í 
density file df3 "cloud.df3" 
interpolate 1 
l 
3 


isosurface ( function £ 0.1 - DENSFUNC(x,y,2) 3 


A fenti példában a cloud.df3 fájl segítségével egy 0,1 értékű 
szintfelület állítanánk elő egy háromvonalas (trilineáris) in- 
terpolációs séma használatával (az interpolációról rövidesen 
lesz még szó). 

A sűrűségfájl formátuma szigorúan kötött, az adatokat 8 bi- 
tes értékek képviselik (0 és 255 közti előjel nélküli egészek), 
amelyeket a program alakít át 0,0 és 1,0 közti értékekre. 
Mivel az én zivatar-adataim 32 bites lebegőpontos értékek, 
a sűrűségfájl-formátum nem alkalmas közvetlenül az erede- 
ti POV-Ray 3.5 változattal való használatra. 

Itt lép be Ryouichi Suzuki, aki 1996 óta fejleszt a POV-Ray 
számára kiegészítő kódokat. Ő készítette a POV-Ray 3.0-hoz 
azokat a foltokat is, amelyek elsőként vezették be a 3.5 vál- 
tozatba már beépített objektumként szereplő szintfelület- 
objektumokat. Suzuki fent említett zip-fájljában lévő kód 
tartalmaz olyan eljárásokat is, amelyek kiterjesztik a POV- 
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2. ábra Egy példa többszörös szintfelületekre, ahol 
a központban a szupercella felhőfalnak nevezett tartománya áll. 
A felhőfal alatt az előtérben látható sárga szintfelületek 
a tornádószerű örvénylő mozgást mutatják. 


Ray sűrűségfájljainak lehetőségeit, képessé téve a progra- 
mot többek közt a lebegőpontos sűrűségfájlok alapján törté- 
nő leképezésre is. 

Amikor sűrűségfájlokat használunk függvények helyett, 
felmerülhet valakiben a gondolat, hogy míg a függvények 
folytonos kifejezések — vagyis az x, y és z térkoordinátákhoz 
bármilyen lebegőpontos érték tartozhat — a sűrűségfájl az 
adatoknak olyan diszkrét halmaza, amelyet a tömbök egész 
indexei jellemeznek. Egy kép leképezésénél a rácspontok 
közti területet interpoláció segítségével kell kitölteni. A két 
rendelkezésre álló interpolációs eljárás a háromvonalas in- 
terpoláció és a háromirányú köbös simulógörbe (tricubic 
spline). A háromvonalas interpoláció gyorsabb, de gyakran 
nem ad olyan egyenletes eredményt, mint a simulógörbe. 


A modelladatok betöltése a POV-Ray-be 

Miután a POV-Ray 3.5-re feltelepítettük Suzuki sűrűségfájl- 
ra vonatkozó foltjait, a rendszer készen áll arra, hogy lebe- 
gőpontos értékek alapján képezzen le szintfelületeket 

— amennyiben az adatok df3 formátumban, vagy Suzuki ki- 
terjesztett formátumában rendelkezésre állnak. Az én ese- 
temben az adatok több száz gigabájtnyi HDF-fájlként 
(hierarchical data format, hierarchikus adatformátum) táro- 
lódnak, amely formátum kifejezetten numerikus modellek 
adatainak a tárolására lett kifejlesztve. Mivel engem nem 
csak néhány szintfelületes kép előállítása érdekelt, hanem 
szerettem volna az előállított több száz, esetleg több ezer 
képből animációt is létrehozni, a HDF-df3 átalakítás nem jö- 
hetett szóba. Ehelyett inkább vizsgálni kezdtem a POV-Ray 
eljárásait, amelyekkel a sűrűségfájlokat kezeli és remény- 
kedtem, hogy sikerül a kódot úgy módosítanom, hogy ol- 
vasni tudja a HDF-fájljaimat. 

Fontos volt számomra az is, hogy a módosításaim ne csök- 
kentsék az eredeti program használhatóságát és teljesen 
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kompatibilis maradjon a folt nélküli változattal. A célomat 
úgy értem el, hogy a jelenetleíró fájlomhoz olyan új objek- 
tumokat adtam, amelyeket a módosított változat képes volt 
elemezni és leképezni, míg az összes többi objektum válto- 
zatlan maradt. Az általam módosított kód központi része 

a pattern.cpp fájlban található, amely a Read Density File 
eljárást tartalmazza. Ahogy a neve is sejteti, ez az eljárás ol- 
vassa be a sűrűségfájlt egy háromdimenziós tömbbe. Ennek 
az eljárásnak a mintájára létrehoztam egy új eljárást 

Read Hdf. File néven, amely az én leírófájlomat olvassa be 
a POV-Ray-be. Ez az a rész, ahol a legtöbb módosítást 
igényli a programkód, ha ragaszkodunk a saját adatformá- 
tumunkhoz. Az 1. listán a Read Hdf. File eljárás rövidített 
változatát láthatjuk. 

A Read Hdf File függvény olvassa be a HDF lebegőpontos 
adatait a mapF nevű háromdimenziós lebegőpontos tömbbe, 
amely ezután már sűrűségfájlként kezelhető. A hystory.c 
fájlban külön írtam meg azokat a kódokat, amelyekre 

a HDF I/O-eljárásai hivatkoznak a pattern.cpp fájlban. A sa- 
ját adatfájl-formátumunkhoz saját magunknak kell megír- 
nunk azt a formátumra jellemző kódot, amely a háromdi- 
menziós adatainkat beolvassa a POV-Ray-be. 

Módosítanom kellett még néhány fájlt annak érdekében, 
hogy a POV-Ray felismerje a HDF fájlformátumot és hogy 
lehetővé váljon képenként egynél több modellváltozó leké- 
pezése. Az 1. táblázat sorolja fel a módosított fájlokat és rö- 
vid leírást ad az elvégzett változtatásokról. 

A HDF fájl a sűrűségfájllal ellentétben lehetővé tesz fáj- 
lonként egynél több változó tárolását is. Az esetemben 
minden egyes HDF fájl a modell egy bizonyos időpontbeli 
állapotát írja le, és fájlonként 12 háromdimenziós változót 
tartalmaz. Gyakran sokkal látványosabb, ha egy képen 
több változót (felhő, eső, jégeső, hó) együtt is megfigyel- 
hetünk. Ennek megvalósítására a HDF fájlformátum ábrá- 
zolásához egy új tokent, a HDF TOKEN-t hoztam létre 
(szemben az eredeti df3 ábrázolását végző DF3 TOKEN 
nevű tokennel), és egy Var nevű új karaktertömböt hoz- 
tam létre a Density file Data Struct szerkezetben. 

A Var a jelenetleíró fájlban kap értéket, és a HDF- 
eljárásoknak paraméterként átadva meghatározza, 

hogy melyik modellváltozó legyen kiválasztva. A ka- 
rakterláncként tárolt változónév értelmezéséhez egy 
további case utasítást adtam a parstxtr.cpp fájl 

Parse PatternFunction függvényéhez (2. lista). Lát- 
hatjuk a Parse Comma és Parse C String hozzáadását 

is, amelyek a beolvasandó változót csípik el. 


A jelenetleíró fájl 

Most már minden részlet a helyén van ahhoz, hogy létre- 
hozzunk egy POV-Ray által értelmezhető jelenetleíró fájlt. 
Ehhez a Suzuki-féle sűrűségfájl-kiterjesztés honlapján meg- 
található példafájlt használtam sablonként egy kicsit az igé- 
nyeimhez igazítva. A 3. lista tartalmazza a teljes jelenetleíró 
fájlt, amit az 1. ábrán látható kék hátterű és burkolófelület- 
tel ellátott felhősűrűség-szintfelület leképezéséhez használ- 
tam. A tetejétől indulva először a $version utasítást látjuk, 
ez teszi lehetővé a nem hivatalos POV-Ray változatom mű- 
ködését. Az ezután következő kilenc declare utasítás 

a szintfelületet tartalmazó téglatestet és a tengelyek beosz- 
tását határozza meg. 


1. lista A Read Hdf File listájának rövidített változata 
a pattern.cpp fájlból 


void Read Hdf File (DENSITY FILE " df) 

í 
Locate Density File(df-5Data-5Name) ; 
df-5Data--Type -— 1; //floating point data 
open HDF File(df-s5Data-s5Name) ; 
//povray needs array dimensions 
Read HDF File Geometry(nx, ny,nz) ; 


df-5Data-3Sx -— nXx; 
df-5Data-sSy — ny; 
df-5Data-5Sz — nz; 


//this array will contain density file data 
Allocate Memory (mapF , nx , ny , nZ) ; 

//read variable into mapF array 

Get HDF File Data(var , mapF , nx , ny , n2) ; 

//density file pointer now points to model data 
df-5Data-sDensityF - mapF; 


2. lista A HDF TOKEN case-ágában szükség van egy 
további elemző részre, amely lehetővé teszi annak meg- 
adását, hogy melyik változó leképezése történjen. 

A kódrészlet a parstxtr.cpp fájl Parse PatternFunction 
eljárásában található. 


EXPECT 
CASE (DF3. TOKEN) 
New-:Vals.Density File-:Data-:Name - 
Parse C String(true) ; 
Read Density File(New-svals.Density File); 
EXIT 
END. CASE 
CASE (HDF.TOKEN) 
New-:2Vals.Density File-:Data-:Name - 
Parse C String(true) ; 
Parse Comma() ; 
New-:Vals.Density File-:Data-sVar -— 
Parse C String(true); 
Read Hdf File(New-svals.Density File); 
EXIT 
END. CASE 


Továbbhaladva a jelenetleíró fájlban a színek és a felület ki- 
dolgozásának paramétereinek, valamint a kameraállás és 
megvilágítás jellemzőinek megadása történik. Az ezt követő 
sorok tartalmazzák a lényeget, a szintfelület meghatározá- 
sát. A OCFUNC egy függvény, amely a forrásadatokat 

a supercell.ck10990.hdf nevű HDF-fájlból olvassa be és ezek- 
ből a leképezéshez a oc változó tartalmát használja fel 
(amely változó a felhősűrűséget tárolja). Az interpolációhoz 
a köbös simulógörbét választjuk, és a teljes tartományra ér- 
vényesítjük a fokbeosztást, így az összes olyan térbeli koor- 


www.linuxvilag.hu 


1. táblázat A modelladatok POV-Ray-ben történő 
alkalmazását biztosító módosítások listája 





Fájl Módosítás 
pattern.cp A modelladatokat beolvasó 
Get HDF File Data eljárás hozzáadása. 
pattern.h A Read Haf File meghatározásának 
hozzáadása. 
parstxtr.cop . A HDF TOKEN case-blokkjának hozzáadása. 


tokenize.cop AHDF TOKEN hozzáadása 


a Reserved Words tömbhöz. 


frame.h A char "Var! hozzáadása 
a Density file Data Struct szerkezethez. 
parse.h A HDF TOKEN hozzáadása a TOKEN IDS-hez.. 


dináta, mint a kameraállás, megvilágítás helyzete, egybe- 
esik az adatértékekkel. Alapértelmezésben a POV-Ray tarto- 
mánya mindhárom irányban a 0,0-tól 1,0-ig terjedő tarto- 
mányt használná. 

Létrehoztam egy OCISOSFC nevű makrót, amely paraméter- 
ként a leképezni kívánt szintfelület értékét és a szintfelület 
átlátszóságát kapja meg. Az szintfelület átlátszósága egy jól 
használható tulajdonság, amikor két egymást fedő szintfelü- 
letet ábrázolunk. Például érdemes áttetszővé tenni a felhőt, 
amikor egyidejűleg jégsűrűség-szintfelületet is ábrázolunk, 
mivel a jég gyakran található a viharfelhők belsejében. 

A makróban leképezés szintfelület-függvényeként a feljebb 
definiált OCFUNC-ot választjuk. A kiválasztott szintfelület azo- 
kat a felhősűrűség-értékeket veszi figyelembe, amelyek na- 
gyobbak a felülethez kiválasztott 0,0002 értéknél. 

A max gradient paraméter lényegében azt határozza 

meg a POV-Ray számára, hogy mennyi munkát fordítson 

a szintfelület meghatározására. A működés szempontjából 
azt rögzíti a program számára, hogy mi az a maximális 
gradiens (változási gyorsaság a távolság függvényében), 
amellyel a függvény egy adott szintfelület-pont környezeté- 
ben lévő felület-adatokat leírja. Ezt a számot nagyon körül- 
tekintően kell megválasztani. Túl kicsire választva az érté- 
ket lyukak lesznek a felületben, esetleg egyáltalán nem ka- 
punk felületet; túl nagyra választva viszont a POV-Ray sok- 
kal hosszabb ideig fog futni, mint az szükséges lenne. Némi 
gyakorlat kell ahhoz, hogy a megfelelő értéket válasszuk. 
Én a 0,0002 értéket választottam, ami a felhősűrűség körül- 
belül 0,0-tól 0,01 értéktartományához viszonyítva első rá- 
nézésre kicsinek tűnik. A POV-Ray egy kép túl nagy vagy 
túl kicsi értékkel végrehajtott leképezése után javasol egy 
olyan értéket, amit a leképezés alapján megfelelőnek tart. 


Képek és egyebek létrehozása 

A program változtatásokkal történő lefordításához néhány 
kisebb módosítást kell végrehajtanunk az src/Makefile fájl- 
ban, amely a POV-Ray könyvtárának felső szintjén lévő 
configure első futtatásakor jön létre. Ez az eset akkor áll 
fenn, ha az adatfájljaink beolvasó eljárásaihoz külső prog- 
ramkönyvtárakat használunk, vagy ha a fájlok [/D művele- 
teit külön kóddal oldottuk meg. 
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3. lista A cloud.pov fájl 


fversion unofficial dfe 3.5; 

finclude "fcolors.inc" 

fdeclare x0 — 0.0; 

fdeclare x1 - 700.0; 

fdeclare yO — 0.0; 

fdeclare yi - 600.0; 

fdeclare z0 - 0.0; 

fdeclare zi — 80; 

fdeclare scalex - (x1-x0341); 

fdeclare scaley - (y1-y031); 

fdeclare scalez - (z1-7041); 

fdeclare R — 0.7; 

fdeclare G — 0.7; 

fdeclare B — 0.7; 

$fdeclare AMBIENT SS0S5G 

fdeclare DIFFUSE a al sata 

fdeclare SPECULAR s 4.35 

fdeclare ROUGHNESS - 0.01; 

fdeclare BRILLIANCE — 1.0; 

camera (í 
up 207051 
sky ao olgal s 
right S3S0S0S0s 
direction SO S0S0S 
location c420,70,703 
look at c370,300,903 

3 


A program lefordítása után a parancssorból indíthatjuk 

a POV-Ray-t. Az alábbi parancs beolvassa a cloud.pov fájlt és 
egy 600x400 felbontású élsimított PPM-fájlt állít elő megje- 
lenítve a képernyőn a leképezés folyamatát: 


/home/orf/povray-3.50c-orf/src/povray 3DN 
Input File Name-cloud width-600 Height-400 4 
Antialias-on Output File Type-P 


Miután az adataink alapján a POV-Ray sikeresen elké- 
szítette a képet, a beállítható eszközök széles választé- 
kával alakíthatjuk a leképezést az igényeinknek legmeg- 
felelőbb formára. Ha folyamatosan változó adatokkal 
rendelkezünk, kézenfekvő igény, hogy ezekből mozgó- 
képet hozzunk létre. Én Python parancsfájlokkal oldot- 
tam meg a különböző POV-Ray példányok indítását 

a leképezőtelepem egyes processzorain, ahol a pro- 
cesszorok párhuzamosan dolgoznak a modell különbö- 
ző időállapotainak adatain. A kapott PPM-fájlokat ez- 
után az mjpegtools segítségével illesztem össze mozgó- 
képpé. A kutatói honlapomról letölthető néhány ilyen 
animáció. Sztereóképeket és mozgóképeket is létrehoztam 
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Tight source £ c100,100,1005 color Gray25 
shadowless3 

Tight source í 
Tight source f 


Tight source ( 


c400,200,303 color Gray20 3 
c1000,-500,1505 color Gray25 3 
c-400,-500,1505 color Gray25 3 


fdeclare OCFUNC - function 1 pattern( 
density file hdf "supercelt.ck10990.hdf", "ac" 
interpolate 2 //tricubic spline 
freguency 0 

scale cscalex,scaley,scalezsz ) 3 


fmacro OCISOSFC(iso, trans) 

isosurfacef  functionf  -OCFUNC(xX,y,2) 3 

threshold -iso 

max gradient 0.0002 

contained byf boxf cx0,yO,ZzOs,cxi,yi,zi? 3 

texturef pigmentfí color rgbt-AR,G,B,transz) 

finishf ambient AMBIENT diffuse DIFFUSE 
specular SPECULAR roughness ROUGHNESS 
brilliance BRILLIANCE? l . shadow 

I 

fend 


OCISOSFC(0.0002,0.0) // render cloud 


box £ cx0,yO,ZzO0s cx1l,y1l,z0s // tiles 5km sguare 
pigment f checker color Newran, 

color .90"Newran scale 503 
finish £ ambient 0.5 diffuse 0.53 3? 


background £ SkyBluej // what else? 


az osztályunk GeoWall rendszere számára. A sztereó 
képpárok létrehozása a POV-Ray számára nem jelent 
gondot és valóban új megvilágításba helyezi az adatain- 
kat. A POV-Ray használata a modelljeim adatainak meg- 
jelenítésére egy sereg új izgalmas lehetőség felé nyitotta 
meg számomra az utat, s remélem, hogy ebben nem 
vagyok egyedül. 

A cikkhez kapcsolódó hivatkozások 

a 5 www.linuxjournal.comj/article/7754 címen érhetőek el. 


Linux Journal 2004. november, 127. szám 


Leigh Orf a Michigani Központi Egyetem 
légkörkutatással foglalkozó professzora, és 
hosszú ideje Linux felhasználó. Tudományos 
kutatási területei közé tartozik a viharok való- 
sághű szimulációja és megjelenítése, amelyek- 
hez nagy teljesítményű Linux-fürtöket használ. 
Szabadidejében élvezettel főzi saját sörét, 
rádióamatőrködik, szaxofonozik vagy indul 
sátortúrára feleségével, Annie-vel. 

A leigh.orfocmich.edu címen érhető el. 








PHP SOLite adatbázisháttérrel 


Eddigi PHP alapokra épülő munkáim során ritka volt az olyan feladat, ahová ne 
jött volna jól egy kis adatbázis támogatás a hatékony adatkezelés érdekében. 
Ámde a PHP-ben legyártott alkalmazások nagy része olyan környezetben éli éle- 
tét, ahol az adatbázis kiszolgáló ugyanazon a gépen található, vagy esetleg egy 


ugyanazon hálózaton figyelő másikon. 


Bevezetés 

Bár az adatbázis szerverek maguk lehetővé teszik, az ilyen 
kis és közepes projektek nem igényelnek többet egy darab 
adatbázis hozzáférést biztosító felhasználónév/jelszó páros- 
nál. De mivel a nyers fájlokkal való izommunka mégsem 
olyan csábító választási lehetőség, marad az SOL adatbázis 
szerverek dolgoztatása, felesleges hálózati rétegekkel, szé- 
leskörű jogosultság rendszerekkel. Ez így is ment mindad- 
dig, míg csak egy napon elém nem került az SOLite, a be- 
ágyazható adatbáziskezelő motor. Bár nem lehet belőle 
nagyvállalati központi adattár kiszolgálót építeni, de saját 
kis webhelyeink blogjainak, fórumainak, on-line boltocskái- 
nak meghajtására kiválóan alkalmas. 

Ez a cikk azok számára lehet hasznos olvasmány, akik már 
foglalkoztak a PHP valamely adatbáziskezelő kiterjesztésé- 
vel, mivel javarészt inkább csak a különbségek, egyedi meg- 
oldások bemutatására szorítkozom. 


Telepítés, rendszerigény 

A PHP SOLIite kiterjesztésének birtokbavétele nem tartozik 
a keményebb rendszergazdai feladatok közé. Az SOLite ter- 
vezésekor az egyik fő szempont pont az volt, hogy könnyen 
illeszthető legyen bármihez, és lehetőleg ne függjön léte 
más függvénykönyvtáraktól. Így ahol a PHP futásképes, 

ott az SOLite-al sem lesz gond. Munkába fogásához csak 

a megfelelő PHP modul telepítése szükséges. A legtöbb ki- 
terjesztéssel ellentétben ennek telepíthetősége nem függ 
külső függvénykönyvtár meglététől, mivel a PHP kiterjesz- 
tés magában foglalja a teljes SOLite függvénykönyvtárt. 
Nos, nem hiába hívják beágyazható adatbáziskezelőnek. 

A PHP 5 esetében az alaptelepítéssel már kezünkben is van 
a teljes SOLite eszköztár telepítve, élesítve. A 4-es változa- 
tok esetében a PHP Pear névre hallgató csomagkezelőjét 
kell kicsit munkára fognunk, a 


pearinstall sglite 


utasítás parancssorba gépelésével, minek eredményeként 
letöltésre, majd gépünkön forrásból fordításra kerül a meg- 
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felelő PHP kiterjesztésmodul. A sikeres fordításhoz a gcc 
mellett szükség lesz az autotools (autoconf, automake) 
eszközökre is. 

Korábbi PHP 4-es változatok esetén előfordulhat, hogy egy 
kellemetlenkedő, 


No releases found for package "sglite" 


üzenetet kapunk próbálkozásunkra. Semmi gond, csak 

a PHP-vel kapott Pegr telepítő kicsit öreg, így előbb saját 
maga frissítésére kell rávennünk. A következő parancs hatá- 
sára ez meg is történik, ami után az sglite csomagot is meg 
fogja találni: 


pear upgrade Console Getopt PEAR Archive Tar 


Siker esetén helyére kerül az sglite.so állomány, melyet vagy 
a php.ini egy megfelelő extension-salite. so sorával, vagy 
a PHP parancsállományaink elejére tett dI("salite.so") 
utasítással tudjuk a PHP részévé tenni. Innentől kezdve ren- 
delkezésünkre áll az sglite parancskészlet. 


Gyorstalpaló 

Az SOLite - hasonlóan a PHP-hez - nem kifejezetten 
típusérzékeny. Valójában jórészt magasról tesz rá, milyen 
típust adtunk meg melyik oszlopnál, egy INT típusú mező- 
be büntetlenül tehetünk szöveget is. A szövegesnek megje- 
lölt oszlopok méretmeghatározása is inkább csak arra jó, 
hogy magunknak dokumentáljuk, körülbelül milyen adato- 
kat is szeretnénk tárolni. Hasznos információvá szinte csak 
a tábla neve és az oszlopnevek válnak. Bizonyos esetekben, 
például rendezések során persze szerepet kap a megadott 
oszloptípus, ami szerint számszerűleg, vagy szövegként 
kezelve rendezi sorba az elemeket. 

Aki már foglalkozott a PHP és valamely adatbázis kiszolgáló- 
típus házasításával, az SOLite modul parancskészlete sem 
fog nagy meglepődéseket okozni. Sajnos ez a modul is a ma- 
ga útját járja, így egyik jelenlegi SOL motorral dolgozó kiter- 
jesztésnek sem felel meg egy az egyben parancskészlete. 
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1. lista 


c?php 
if (!function exists("sglite fetch single")) ( 
function sglite fetch single($res) ( 
$row - sglite fetch array($res, 
s SOLITE NUM) ; 
return $row[0]; 


Mivel nincs külön adatbázis szerver, kapcsolódnunk nem 
kell hozzá, valamint jelszó sem kell az adatbázis eléréséhez. 
Ez a művelet inkább hasonlatos ahhoz, ahogy egy fájlt 
megnyitunk: 


$db - sglite open(cfájlnév:, 
5 [ghibaüzenet]); 


[fájljogok] , 


Az egyetlen, amit mindenképp meg kell adnunk, az SOLite 
val egyetemben. A második paraméter alapértéke a 0666 
oktális érték, ami a rw-rw-rw- fájljogosultságnak felel meg. 
Jelenleg ezen paraméternek nincs jelentősége, bármit is 
adunk meg, az SOLite ezzel a móddal fog próbálkozni. 
Harmadik paraméterként megadhatunk egy változót, ami- 
be az esetleges szöveges hibaüzenet kerül, ha az adatbázis 
megnyitása kudarcba fulladt volna. Ilyen esetekben az 
sglite openO amúgy false értékkel fog visszatérni. 
Amennyiben a megadott helyen nem található a keresett 
fájl, ezen utasítással létre is hozzuk azt, feltéve ha erre 

a könyvtárra a webszerver felhasználója megfelelő jogosult- 
ságot kap. Fontos tudni, hogy nem elég, ha a létrehozás 
idejére adunk csak írási jogot a hordozó könyvtárra. Az 
adatbázis módosításához, bővítéséhez ugyanis nem elég, 
ha magát a fájlt tudjuk írni, mivel ezen műveletek során 
ugyanitt ideiglenes állományok létrehozására is szüksége 
lesz SOLite motorunknak. Amint sikeresen rendelkezünk 
egy megnyitott adatbázissal, minden úgy megy, ahogy azt 
más adatbázisoknál is megszokhattuk. Az SOL kérések fut- 
tatására az sglite gueryO) valamint az sglite execO 
szolgál, míg az eredménylisták kisajtolására az 

salite fetch " függvények. Munkánk végeztével egy 
esetleges sglite closeO által felszabadíthatjuk lefoglalt 
erőforrásainkat. 

Az salite agueryO és salite execO is SOL parancsok 
végrehajtására szolgál, de csak az első ad vissza eredmény- 
listát. Az sglite execO) csupán igaz/hamis értéket ad attól 
függően, hogy a parancs futtatása sikeres volt, vagy sem. 
Ezen függvények két adatot várnak, a megnyitott adatbá- 
zisra mutató erőforrás azonosítót, valamint magát az SOL 
kérést. A két paraméter tetszőleges sorrendben megadható, 
a kézikönyv az adatbázis azonosító előre vételét javasolja. 
Aki sokat dolgozott például mysg1-el, esetleg kényelme- 
sebbnek találhatja az ott megszokott sorrendet. Egy pa- 
ranccsal egyszerre több SOL kérést is futtathatunk, ezeket 
az saglite execO minden esetben futtatni fogja maradék- 
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2. lista 
c?php 


/" Ideiglenes adatbázis létrehozása tesztadatok- 
kal §/ 
$db - sglite open( " :memory: " ) ; 
sglite exec($db, "CREATE TABLE ertekek (szam)"); 
foreaecnu latta At ss33 NSZ ZZZ ÉKES Z Eza 
5 $szam) ( 
sglite exec($db, "INSERT INTO ertekek VALUES 
SAE Sszamíe JE 


/" Saját (1Ientebb megvalósított) függvényeink 
átadása SOLite-nak "7/ 

sglite create aggregate($db, 
5 "avg feldolgozo" , 
salite create function($db, 


tavg" , 
"avg. osszegzo" ) ; 
"dup", "dup"); 


/" Lekérdezés, melyben használjuk mindkét függ- 

vényt "/ 

$res - sglite guery($db, "SELECT avg(dup(szam)) 
5 FROM ertekek"); 

echo sglite fetch single($res); 

sglite close($db); 


/" Az SOLite számára elállított függvények "/ 
function dup($ertek) ( 
return $ertek " 2; 


function avg feldolgozo($kornyezet, 
5 $aktualis ertek) ( 
$kornyezet["osszeg"] -- $aktualis ertek; 
$kornyezet["elemek"] -- 1; 


function avg. osszegzo($kornyezet) ( 
return ($kornyezet[ "osszeg" ] / 
5 $kornyezet[ "elemek" ]) ; 


Hi 


talanul. Az sglite gueryO) csak akkor, ha a visszakapott 
eredményazonosítót a későbbiek folyamán nem használjuk 
fel. Ha mégis, akkor csak az első kérés fog végrehajtódni. 
Sikeres lekérdezés után jön az adatkinyerés az eredménylis- 
tából. Teljes, több mezős adatsort, az saglite fetch arrayO 
függvénnyel tudunk olvasni. Első és egyetlen kötelező para- 
méterként az eredménylista azonosítót várja. Ellentétben 
más adatbázis kiterjesztésekkel, itt nem áll rendelkezésre 
salite fetch rowO függvény. Erre is az előbbi alkalma- 
zandó, a második paraméterben megadva, milyen formában 
kérjük az adatsort. Ehhez az SOLite kiterjesztés három előre 
megadott állandót alkalmaz: 








e  SOLITE ASSOC - a mezőnévnek megfelelő indexre teszi 
az értékeket 

e  SOLITE NUM — a mező sorszámának megfelelő indexre 
teszi az értékeket 

e — SOLITE BOTH mind név, mind oszlopszám szerint is 
elhelyezi az adatokat 


Ha amúgy is egy nagy tömbbe szeretnénk ciklikusan beol- 
vasni a teljes eredménylistát, érdemes salite fetch al10- 
ra bízni ezt. Ez a teljes eredménylistát beolvassa egy tömb- 
be, melynek minden eleme egy adott sor lesz. Paramétere- 
zésre teljesen megegyezik az előzővel. Mivel ekkor a teljes 
visszakapott adatsor a memóriába kerül, nagy listák lekéré- 
sekor ez a módszer nem javallott. Általában azonban igaz, 
hogy 50 sornyi adatnál többet amúgy sem illik a látogató 
orra alá dörgölni egyszerre. 

Az ilyen tömbbe lekérdezésre van viszont az SOLite 
kiterjesztésnek egy még kényelmesebb változata. Ezt 

sglite array gueryO néven érhetjük el és egyesíti az 
sglite gueryO valamint az sglite fetch all O függvé- 
nyeket. Első két paramétere a kéréstuttató függvényekével 
egyezik meg, harmadikként pedig megmondhatjuk, milyen 
formában kérjük az adatokat a tömbbe helyezni. 
Számomra szimpatikus, hogy az egyetlen adat lekérését 
megkönnyítendő, létezik egy saglite fetch singleO 
függvény. Ez sajnos a PHP 4-es változatokhoz telepíthető 
kiterjesztésben nincs benne, de a PHP 5 tartalmazza. 

Az 1. lista bemutat egy egyszerű kódocskát mellyel eme 
hiány 4-es változatokban áthidalható. 


Ennyivel a mindennapokban nagyjából el lehet boldogulni, 
csupán csak a hibakeresésről nem esett szó. Ez itt két lépés- 
ben történik, először meg kell tudnunk a feltételezett hiba 
kódját. Erre az saglite last errorO függvénnyel nyílik 
lehetőség. Egyetlen paraméterében sajnos mindenképp 
meg kell adni, mely adatbázissal kapcsolatban érdekel ez az 
adat. Máshol, például a MySOL kiterjesztés esetében alap- 
értelmezésként a legutóbb megnyitott adatbázist veszi elő 
ilyen adat hiányában. Persze egy hibát azonosító szám nem 
sokat segít a hiba felderítésében. Többre jutunk, ha a hiba- 
kódot az salite error. stringO függvénnyel lefordíttat- 
juk emberi nyelvre. A hibakódért cserébe ez annak szöve- 
ges változatát adja vissza. 


Szorosabb együttműködés 

A kisebb erőforrás igények mellett a beágyazottságnak van 
még egy nagy előnye. SOLite kéréseinkben tetszőleges bo- 
nyolultságú, PHP-ben írt függvényeinket is alkalmazhatjuk. 
Néhány alapvető függvénnyel az SOLite is rendelkezik, de 
akár ezek felülírására is képesek vagyunk. Ehhez először is 
létre kell hoznunk egy, a célt megvalósító PHP függvényt, 
mely a bejövő adat(ok)on tetszőleges műveleteket végezve 
végül visszaad egy értéket. Ez csak az SOLite által is értel- 
mezhető adat lehet, azaz nem adhat vissza tömböt, objektu- 
mot, erőforrás hivatkozást. Ha függvényünk harcra kész, 

az salite create functionO függvény segítségével tu- 
dathatjuk, hogy azt az SOLite lekéréseiben alkalmazni sze- 
retnénk. Első paramétereként az adatbázis azonosítót, má- 
sodikként és harmadikként pedig egy-egy függvény nevet. 
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Először a függvény lekérésekben használatos nevét, majd 
a már létrehozott PHP megvalósítás nevét kell megadni. 
Negyedik adatként megadhatjuk az SOLite motornak, 
hány paramétert várjon el ez a függvény. 

Az már csak a fantázián múlik, a függvényen belül mi- 
hez kezdünk a kapott adattal. Akár más típusú adatbázis- 
okhoz is hozzáférhetünk, IP cím alapján kideríthetjük 

a hozzá tartozó gépnevet. Persze a lekérés hatékonysága 

a feladatok bonyolultságának növekedtével alaposan 
visszaeshet. 

Nem csupán az egyes értékek módosítására van lehetősé- 
günk, de a COUNTO, SUMO) és hasonló, a teljes eredmény- 
listát áttogó függvényeket is létrehozhatunk PHP nyelven. 
Az sglite create aggregateC) által hozhatjuk ezt adat- 
bázisunk tudtára. Elsőként ez is az adatbázist kéri beazo- 
nosítani, másodikként pedig a majdani SOL kérésekben 
alkalmazott függvénynevet kell meghatározni. Az átfogó 
függvény megvalósításához azonban két különálló függ- 
vényre lesz szükség. Ezeket adhatjuk meg a harmadik, 
illetve a negyedik paraméterekben. Így ötödik helyre 
csúszik annak megadási lehetősége hány paramétert 

is vár függvényünk. 

A megadandó függvénypár első tagja minden egyes 
kapott soron végrehajtásra kerül, majd végül az adat- 
gyűjtés végeztével a második függvény fogja megmon- 
dani a választ. Első paraméterként mindkét függvény 
egy tetszőlegesen felhasználható, referenciaként kezelt 
változót kap, nevezzük ezt , környezetnek". Ebben a so- 
rok feldolgozása idején tetszőleges méretű adathalmazt 
tárolhatunk. Végül az összegző függvényebből okos- 
kodhatja ki az eredményt. Ha lehetséges, érdemes amit 
csak lehet már menet közben kiszámítani és minél keve- 
sebb nyers adatot tárolni feleslegesen. Ugyanis nagy le- 
kéréseknél egy hatalmasra növekvő tömb csak kiverné 

a biztosítékot. Az összegző függvénynek nincs is szüksége 
más adatra, mint erre a környezetleíró adat(halmaz)ra. 
A soronként meghívott függvény ezután minimum egy, 
de akár több adatot is várhat, szükség szerint. A 2. lista 
egy nem túl bonyolult példát mutat mind az egyedi 
adatokkal dolgozó, mind az átfogó függvények létreho- 
zására és alkalmazására. 


Tippek, tanácsok 

Az egyik legszembetűnőbb hiányosság a jelenlegi SOLite 
motornak az ALTER TABLE megvalósításának teljes hiá- 
nya. Meglévő tábláink felépítésének módosítása így nem 
egy egy sorban kifejezhető hétköznapi feladat. A dolgot 
kézzel kell megcsinálnunk, és mivel a RENAME TABLE is 
hiányzik a megvalósított műveletek közül, ez csak hat 
lépésben oldható meg: 


e  Létrehozunk az eredetivel megegyező felépítésű átme- 
neti táblát. 

e Az eredeti tábla tartalmát átmásoljuk ebbe az átmeneti 
táblába. 

e Töröljük az eredeti táblát. 

e  Létrehozzuk az eredeti nevén az új táblát, új felépíté- 
sében. 

e — Visszamásoljuk az adatokat az eredeti táblából. 

e Töröljük az átmeneti táblát. 
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Érdemes odafigyelni, hova kerül webszerverünkön az sglite 
adatbázisfájl. Hasonlóan ugyanis, mint egy rossz helyre 

tett inc állomány, ez is könnyen rossz kezekbe kerülhet. 
Érdemes tehát azt olyan helyre tenni, amelyet a webszerver 
közvetlenül nem tud kifelé közvetíteni, de a PHP hozzáfér. 
Mint a 2. listában is látható, létrehozható ideiglenes, csak 

a memóriában élő adatbázis is. Ez ellentétben a MySOL 
HEAP típusával szemben a létrehozó program futásának vé- 
geztével megszűnik létezni. Ha ilyen átmeneti adatbázisra 
van szükség, fájlnév helyett adjuk fájlnév helyett :memory : 
értéket megnyitáskor. 

Az automatikusan növekvő értékű mezők (mint a MySOL 
AUTO. INCREMENT-je, vagy a PostgreSOL sorozatai) létrehozá- 
sa SOLite-ban roppant egyszerű. Elég, ha a mező az elsőd- 
leges kulcs (PRIMARY KEY), típusa pedig számszerű, egész 
(INT). Az ilyen mezőknek NULL értéket adva azok időben 
növekvő, egyedi értéket kapnak. 

Az SOLite nem rendelkezik külön beállításokat tartalmazó 
állománnyal, telepítése után azonnal üzemkész. Természe- 
tesen egyedi finomításokra, beállítgatásokra sokszor szük- 
ség lehet. Az ilyen feladatok elvégzésére szolgál az SOLite 
PRAGMA parancsa, mellyel egyedi beállításokat érvényesíthe- 
tünk, de ez által gyűjthetők be bizonyos információk is. 

A PRAGMA parancsok a többi SOL kéréssel teljesen azonos 
mód hívhatók. Néhány olyan, amelyre hamar szükség lehet 
a mindennapi munka során: 


PRAGMA table info(tábla neve) 


Az adott tábla szerkezetét kapjuk vissza, minden mezőre 
megkapva az oszlop nevét, típusát, hordozhat-e NULL érté- 
ket, valamit az alapértelmezett értékét. 


PRAGMA cache size — érték 


Az alapértelmezett 2000 lapos gyorstár méretet bírálhatjuk 
felül vele. Egy lap mérete körülbelül 1,5 K. Nagyobb érté- 
ket adva nő a memóriafogyasztás, de cserébe gyorsabb mű- 
ködésre bírhatjuk lekérdezéseinket bizonyos esetekben. 


PRAGMA short column names-ON/OFF 

Ellentétben a korábbiakkal, az aktuális SOLite változatok több 
táblás lekérés esetén a a mező nevet a tábla nevével együtt, 
ponttal elválasztva adják vissza. A fenti kapcsolót ON-ra állítva 


az SOLite rávehető, hogy csakis az oszlopnevet adja vissza. 


Heilig Szabolcs 


Michael Owens: SOL adatbázis beágyazása az 
SOLite segítségével (Linuxvilág, 2003. augusztus, 
26-29. oldal) 


5 http://hu.php.net/salite 


5 http://sglite.org 

















Reklámsáv és logó a GIIMP-pel 


Így az tél közeledtével, mindenki kissé visszavonultabb életet él, tehát bizonyára 
több ideje van foglalkozni a rajzorogramokkal. Ilyenkor elkezdhetünk gondolkodni 
a tavaszi újításainkon is. Ilyen lehet például a honlapunkon a reklámcsíkok lecse- 
rélése vagy új logó tervezése a cégünk arculatához. 


indezért nem szükséges nagy pénzeket kifizetni, 
rút] elegendő csupán elolvasni az alábbi bekezdése- 

ket, majd a GIMP-et elindítva máris megkezd- 
hetjük a munkát. Az alábbi példában a képzeletbeli Kuty- 
Ham Kft. honlapján lévő címsort készítjük el, végeredmé- 
nyül pedig majd az 1. ábrán látható feliratot kapjuk. 
Lássunk is hozzá a feladat megoldásához. Miután elindítot- 
tuk a GIMP-et, hozzunk létre egy üres képet. Szerencsére 
a 2.0 változatban már tudunk sablonból is létrehozni képe- 
ket. A CTRL-N billentyűk hatására megjelenő párbeszédab- 
lakban a 2-es képen pirossal keretezett részen választha- 
tunk a különféle sablonok közül. Válasszuk ki a Web banner 
Huge változatot, majd adjunk meg nagyobb magasságot. 
A kép létrehozása után folytathatjuk a munkálatokat a szö- 
veg elkészítésével. 
Válasszuk ki a dinamikus szövegek létrehozására alkalmas 
eszközt, melyet T betű formájú ikonjáról ismerhetünk fel. 
Kattintsunk valahová a képen, ahol feltehetően kezdődni 
fog a felirat és az eszközbeállításoknál válasszuk ki a megfe- 
lelő betűtípust és méretet. A kis ablakban a szövegmezőbe 
írjuk be a felirat szövegét. Zárjuk be a párbeszédablakot, 
majd a létrehozott szöveget helyezzük el a megfelelő helyre 
a rétegek mozgatására szolgáló eszközzel. Ezt az eszközt 
a négy irányba mutató nyíl jelzi. Talán kezdetben kicsit 
nagyra választottuk a képméretet, de ez nem okozhat gon- 
dot kedves olvasóimnak, hiszen a kép levágására is mutat- 
tam eszközöket az előző részekben. Alakítsuk ki a megfele- 
lő méretet, de vigyázzunk arra, hogy az árnyéknak is kell 
majd hely, tehát nem szabad pontosan levágni a karakterek 
szélénél a képet. 
A méret meghatározása után következhet a színezés. 
Válasszuk ki a színek alapján a fekete képpontokat. Az új 
GIMP-ben már az eszköztáron is megtalálható a szín sze- 
rinti kiválasztásra alkalmas eszköz, amit egy színes négyze- 
tekre mutató kéz jelez. Válasszuk ki tehát a fekete színt 
a képről, majd készítsünk átmenetet. Keressük meg a cég 
arculatához leginkább illeszkedő átmenetet vagy készítsünk 
tetszőleges, új átmenetet a GIMP segítségével. Mindenki- 
nek saját ízlése szerint kell eljárnia a következő lépéseknél, 
de ennek ellenére én is leírom az általam alkalmazott meg- 
oldást. A Golden elnevezésű átmenet kiválasztása után beál- 
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1. ábra A cél: új címsorunk elkészítése 
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2. ábra Új kép sablonból 


lítjuk az átmenet típusát, ami jelen esetben a Gömbölyű 
shapebrust. Mivel a kijelölés illeszkedik a betűk formájához, 
elég csak egy rövid, vízszintes részen megadni a színátme- 
net irányát, hogy a képen látható hatást elérjük. 

A festés után következzen az árnyék létrehozása, melyet 
egy beépülő modullal készíthetünk el. A kijelölés maradjon 
változatlan és a kép menüjében a Script-Fu menüpontból 

a Shadow-: Drop Shadow pontokat választva készíthetjük 


2004. december 91 


0 Kiskapu Kft. Minden jog fenntartva 





o SSE Kft. Minden jog fenntartva 











 "Untitled-6.0 (AGB, 1... 4 (E1(-1(Elbe 


File Edit Select View Image Layer 
el 


ÉT Hg iz 
"Untitled-4.0 (RGB, 1...) [1(-I(Elbed 


File Edit Select View Image Layer 


[E(-I[Elea 
About 
r Script Arguments 


Text: (Load Game 
Font Size (pixels): [28 [5 
Sans Bold 


Script-Fu: Buttons/Ro... 


Buttons/Round Button 





Hl 





Button [Button (BAA KB [Button (BAA KB KB) 


Font: 















b o 100 150 2 
[ Upper Color (Active): [lsz] 
zi[[4 o] 
A —— 8 iewercotortactvet. ENNI 
Button (84.4 KB) Cancel 
Text Color (Active): [KKK 
"Untitled-5.0 (AGB, 1... 44 (z1(-I(EIBd Paddingx:[4. E) 
File Edit Select View Image Layer Paddin B E 
gyY:[4 ge 
ve Bevel Width: [2 Bi 
Round Ratio: (1.00. [6 


c ddanáláátnál ; 


Button [Button (B4.5KBY 5KB) ancel 


[7 NotPressed 
[7 NotPressed (Active) 














[7 Pressed 





My Home 








3. ábra Gombok beépülő modul segítségével 


el az árnyékot. Az alapbeállítások (8 képpontnyi eltolás 
mindkét tengely irányában) megfelelőek, de tetszés szerint 
meg is változtathatjuk őket. Miután létrehoztuk a vetett 
árnyékot, következhet a betűkön látható körvonal, melyet 
szintén színátmenettel tudunk kitölteni. A kijelölést most 
alakítsuk keretté, mégpedig a kép menüjében található 
Kijelölés- 2 Keret menüpontok kiválasztásával. Adjunk meg 
tetszőleges értéket, a példában három pixeles keretet hasz- 
náltam. Így újra alkalmazhatjuk a színátmenettel történő ki- 
töltést. Ezzel a lépéssel már a felirat rendben van, tehát fog- 
lalkozhatunk a háttérrel és a különféle egyéb hatásokkal. 

A háttér réteget válasszuk ki a rétegek kezelésére szolgáló 
ablakban, majd hozzunk létre egy új réteget fehér színnel. 
Az újonnan létrejött réteget töltsük ki valamilyen szürkés- 
kék árnyalattal, de itt sem szabad határt szabnom az olva- 
sók kreativitásának, tehát mindenki a neki megfelelő szín- 
nel töltheti ki a réteget. A réteg átlátszóságát vegyük körül- 
belül 50 százalékosra, majd a megjelenítés módját állítsuk 
Szorzás-ra. Ez utóbbi meghatározható az átlátszóság meg- 
adására szolgáló csúszka feletti listában. Miután elvégeztük 
a színezésre szolgáló réteg beállításait, válasszuk ki a legalsó 
"Háttér" réteget, és hozzuk létre a mintázatát. A kép menü- 
jében a Filters-: Artistic-- Apply Canvas menüpontokon 
keresztül hozhatunk létre vászon mintázatot, vagy ha ma- 
gyar nyelv van beállítva a GIMP-ben, akkor a Szűrők-: 
Művészi-: Apply Canvas menüpontok kiválasztásával. 
Adjuk meg a megfelelő értékeket és hozzuk létre a vászon- 
mintázatot. 

A vászon színét többféleképpen is meghatározhatjuk. 

A másik megoldás az lehet, hogy nem készítünk félig átlát- 
szó szűrőréteget, hanem helyette kiválasztjuk a háttér réte- 
get és a kép menüjében a Réteg-- Színek-: Colorize menü- 
pontokon keresztül megjelenő párbeszédablakban megha- 
tározzuk a vászon színezetét, telítettségét és világosságát. 
Amint látható, Linux eszmeiségéhez méltó programmal 
találkoztunk, a feladatok megoldása során több utat is be- 
járhatunk, újabb és újabb ismeretekhez juthatunk általuk. 
Az alábbiakban más megoldásokat is mutatok a feliratok 
elkészítésére, bevezetve ezzel kedves olvasóimat a GIMP 
bővítéseinek lehetőségeibe. 
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4. ábra Feliratok beépülő modulokkal 
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5. ábra ,Nékem térkép e táj..." 





A program egyik nagy előnye, hogy magunk is írhatunk 
beépülő modulokat, mindazon függvények használatával, 
melyre a GIMP rutinjai lehetőséget adnak. Az újabb válto- 
zatban már nem csupán a bonyolult formával rendelkező 
Scheme programnyelven készíthetünk ilyen kiegészítőket, 
hanem az egyik legkönnyebben megtanulható program- 
nyelven is, Python programokat írhatunk. Így azok is élvez- 
hetik a bővítés előnyeit, akik mindeddig nem tanultak sem- 
milyen programozási nyelvet, mivel a Python egyszerűsége 
ellenére egy hatékony eszköz a kezdők kezében is. A képek 
elkészítése során gyakran találkozhatunk olyan ismétlődő 
feladatokkal, melyeket érdemes rövid kis programokban 
összefoglalni. A következő hónapokban ilyen programok- 
kal ismerkedhetünk meg, betekinthetünk elkészítésük 
menetébe. Most azonban ízelítőül lássunk néhány példát, 
miről is lesz majd szó. 

A beépülő modulok mindegyikében meghatározható, hogy 

a program menürendszerében melyik almenüben kapjanak 
helyet, így az eddigiek során is találkozhattunk már velük. 
Amikor azonban nincs megnyitva egyetlen kép sem, a GIMP- 
ben ilyenkor is elérhetünk bizonyos beépülő modulokat. Jel- 
lemzően ezek a modulok új képek előállítására szolgálnak. 
Tekintsük meg az eszköztár menüjében az Xtns-: Script-fu 
menüpontokat. Látható, hogy a kiinduló képet nem igénylő 
modulok között számos lehetőséget találunk például gombok 

















vagy feliratok elkészítésére. Ilyen gom- 
bokat láthatunk a 3-as képen is, most 
azonban válasszuk ki, a menüből 

a Buttons almenüt, és készítsünk ma- 
gunk is egy tetszésünknek megfelelő 
gombot. A gombokat felhasználhatjuk 
majd játékunkban, honlapunkon vagy 
ízlésünknek szerint más helyen. 

A képen látható gombok elkészítésé- 








ben az Internetről letölthetjük majd sa- 
ját igényeinknek és számítógépünknek 
megfelelően forráskódból telepíthetjük. 
Sajnos egyenlőre még fiatal lehetőség- 
ről van szó, ami azt jelenti, hogy pilla- 
natnyilag nincs túl nagy választék 

a Python-Fu használatával készült mo- 
dulok között, de mindenesetre ígéretes 
vállalkozásnak látszik. Mindezt amiatt 








hez válasszuk ki a Xtns-: Script-Fu-2 
Buttons-:- Round Button menüpontokat 
és a megjelenő párbeszédablakban ír- 
juk be a kívánt szöveget. Itt állíthatjuk 
be, hogy milyen színekkel készüljön 

a gomb, választhatunk betűtípust, betű- 
méretet, megadhatjuk a gomb feliratát 
és meghatározhatjuk, hogy milyen álla- 
potokhoz készítsen a program képeket. 
Egy gomb általában három állapotú le- 
het, lenyomott, ki nem választott és ki- 
választott. Ebben a beépülő modulban 


6. ábra Kiindulási kép a varázsgömbhöz 





gondolhatja az ember, mivel a Script-Fu 
kiegészítők kínálata az évek során nem 
változott jelentősen, talán éppen azért, 
mert a Scheme nyelv nem tartozik a leg- 
egyszerűbben elsajátítható programozá- 
si nyelvek közé. A későbbiekben látni 
fogjuk majd, hogy a zárójelek tömegé- 
ben még a gyakorlott szem is könnye- 
dén eltéved. Jómagam azt gondolom, 
hogy kezdetben nem szenvedünk sem- 
milyen hátrányt az által, ha a Python 
modulokkal ismerkedünk meg. 





kiválaszthatjuk a szükséges állapotokat, 
majd az OK gombra kattintva máris 


7. ábra Már alakul... 


ízelítőül lássunk néhány ilyen példát 
az legalapvetőbb Python programok 





elkészül a megadott beállításoknak 
megfelelő gomb. 

Sokan a GIMP-et honlapjuk díszítései- 
nek elkészítésére használják, vagyis sok 
esetben szükség lehet feliratok készíté- 
sére. A beépülő modulok között szép 
számmal akadnak ilyen feliratok előállí- 
tására alkalmas programok, melyeket az 
eszköztáron a Xtns-5 Script-Fu-: Logos 








igénybevételével és tekintsük meg a mel- 
lékelt képeket. Hozzunk létre kiindulá- 
si alapként egy árnyékolt gömböt. Vá- 
lasszuk ki a Xtns-5 Pyhton-Fu-: Test-: 
Sphere menüpontokat, majd állítsuk be 

a gömb színét valamilyen tetszőleges 
kék színre. Ezután következzen a ködö- 
sítés, vagyis a kép menüjében válasszuk 
ki a Python-Fu-: Effects-2 Add Fog me- 

















menüpontok kiválasztása után tetszés 
szerint kipróbálhatunk, tesztelhetünk és 
kiválaszthatjuk az adott feladathoz leg- 
jobban illőt. Érdemes próbálkozni a különféle színbeállí- 
tásokkal, hiszen a próbálgatás hozhatja meg a megfelelő 
tapasztalatot, így választhatjuk ki majd a szívünkhöz és 
gondolkodásunkhoz legközelebb álló változatot. Ilyen fel- 
iratokra látható néhány példa a négyes képen. 

Haladjunk tovább a menüben és lássuk mire képes még ez 
a programnyelv és a GIMP. A beépülő modulok között ta- 
lálhatunk különféle mintázatok előállítására alkalmas dara- 
bokat is. Ilyenek például az 5-ös képen látható térképszerű 
tájak előállítására alkalmas Land és a Flat Land amelyek 
szintén jó szolgálatot tehetnek a játékunk- vagy térképésze- 
ti alkalmazásunk reklám oldalának elkészítése során. 

Sok esetben szükségünk lehet arra, hogy egy szöveges do- 
kumentumban található, előre elkészített szöveget helyez- 
zünk el a képeinken. A Xtns-: Script-Fu- : Utils-2 ASCII To 
Image menüpontok kiválasztásával megadhatunk egy ilyen 
szöveges állományt, majd a beépülő modul segítségével 

a GIMP előállítja a szöveget tartalmazó képet. Ebben az 
esetben a GIMP tulajdonképpen minden szövegsorhoz 

új réteget hoz létre, tehát az egyszerűbb kezelés érdeké- 
ben célszerű a szöveget tartalmazó rétegeket egyesíteni. 
Amint korábban már említettem, a másik lehetőségünk 

a külső programok írásához a Python programozási nyelv 
elsajátítása és használata. Előfordulhat, hogy a terjeszté- 
sünk nem tartalmazza a Python-Eu modult, ebben az eset- 
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8. ábra Íme a végeredmény 


nüpontokat és a köd színét válasszuk 
citromsárgára. A hatás létrehozása után 
még egy Python eszközt használunk, 
mely a Python-Eu-: Distorts-2 Whirl and Pinch nevet viseli 
és egyfajta örvénylő mozgást jelenít meg a kiválasztott réte- 
gen. Jelenleg ha nem változtattunk semmit, akkor a kiválasz- 
tott rétegünk a ködöt jeleníti meg, tehát a szűrő alkalmazása 
után a sárga köd örvényleni látszik. Az utolsó előtti lépés 

a hetes képen látható gömb előállításához a rétegműveletek 
megváltoztatása. A rétegek kezelésére szolgáló ablakban állít- 
suk be a ködöt megjelenítő réteget, hogy a GIMP csak a szí- 
neket vegye figyelembe, vagyis válasszuk ki a Color típust. 
Végezetül készítsünk egy rétegmaszkot, ami csak a gömbön 
engedi megjelenni a sárga ködöt. Jelöljük ki a gömböt, majd 
a köd rétegén jobb gombbal kattintva válasszuk ki a Add 
Layer Mask lehetőséget. A maszk forrása legyen a kijelölt te- 
rület (Selection). Ezzel a néhány lépéssel — melyeket nyomon 
követhetünk a 6-es ábrától kiindulva -, láthatóan kevés kéz- 
zel végzett művelettel elkészíthetjük "varázsgömbünket . 
Ebben a hónapban ennyi fért a GIMP-ről szóló bemuta- 
tómba, a következő lapszámokban azonban részleteiben 

is ismertetem a Python beépülő modulok készítésének le- 
hetőségeit. Bízom benne, hogy ezáltal mindenki számára 
világossá válik: a programírás nem nagy kunszt, csupán 
elhatározás és néhány száz oldalnyi jófajta szakirodalom 
elolvasása kell hozzá. 


Fábián Zoltán 
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A pingvin igenis vándormadár 13. rész) 


Avagy használjunk Linuxot a mobil eszközökön. 


Sorozatomnak ebben a részében megvizsgálunk néhány , laptop specifikus" 
X beállítást, továbbá olyan felhasználói programokat, amelyeknek minden 
notebook felhasználó nagy hasznát veheti. 


Hogyan állítsuk be az X-et? 

Aki telepített már asztali gépre Linuxot és hozzá grafikus 
felületet, az most némiképp joggal gondolhatja úgy, hogy 
ez triviális. Én is azt hittem egészen addig, amíg közelebbi 
barátságba nem keveredett a notebookom és a Linux. A te- 
lepítés maga tényleg teljesen hasonlóan zajlott, mint a régi 
asztali gépemnél, de amint végeztem, máris jöttek a problé- 
mák. A videókártya meghajtóprogramja valahogy nem volt 
az igazi. Nem volt OpenGL támogatás, a touchpad érintésé- 
re az egér kurzor őrült táncba kezdett és még sorolhat- 
nám... Most ezeket a problémákat és megoldásukat szeret- 
ném bemutatni, hátha valakit ezzel egy több napos fejfájás- 
tól tudok megkímélni. 


A felbontás beállítása 

Az xfree86 csomagok telepítése közben elindul egy 
szkript, amelynek segítségével be tudjuk állítani a note- 
bookunk kijelzőjét. Először is jelöljük meg, hogy LCD kép- 
ernyőt használunk, aztán folytassuk a kijelző paramétere- 
ink megadásával. 

A legújabb notebookok némelyike már gyönyörű nagy fel- 
bontású kijelzőkkel rendelkezik, ám például az 1400x1050- 
es felbontás olyan messze áll a VESA szabványtól, mint 

a Microsoft a nyílt forráskód támogatásától. Ez bizonyos 
modellek esetében komoly problémát jelenthet, ugyanis 
egyszerűen képtelenek leszünk normális felbontással hasz- 
nálni a gépünket. Ilyen például az Acer Travelmate 600-as 
sorozat némelyik tagja. Ezeknél a gépeknél ugyanis a BIOS 
nem igazolja vissza az X-nek a kért felbontást, így az X nem 
indul el ebben a felbontásban. Ugyan használhatjuk a gé- 
pünket 1280x1024-es felbontásban, ám jó ha tisztában va- 
gyunk vele, egy LCD képernyőt ha nem a fizikai felbontá- 
sában használunk, akkor jelentősen romlik a kép minősége, 
ugyanis a képernyő ennél a technológiánál tényleg fizikai- 
lag képpontokból áll. Egy-egy képpont egy-egy LED hár- 
masból (piros, zöld, kék LED) áll, így ha fél képponttal kéne 
csúsztatni, akkor egy LED-nek két fél képpontot kéne meg- 
jeleníteni, ami fizikai képtelenség. A régi kijelzők ebben az 
esetben vagy levették a megjelenítendő területet akkorára, 
amekkora felbontásra állítottuk, vagy irtózatosan ronda ké- 
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CELÜLE 


LE 


spend Resume Eject Insert 


ai 


kari 


legal cardinfo 


1. kép A cacrdinfo program felhasználói felülete — Flash 
memóriakártyával a foglalatban 


UPD720130 

Manufacturer: Gerlight 
Speed: 480Mb/s (high) 
USB Version: 2.00 

Device Class: 00(ifc ) 
(Device Subclass: 00 
Device Protocol: 00 
Maximum Default Endpoint Size: 64 
Number of Configurations: 1 
Vendor Id: 1402 

Product Id: 0001 

Revísion Number: 0.00 


Config Number: 1 
Number of Interfaces: 1 
Attributes: c0 
MaxPower Needed:  2mA 


Interface Number: 0 
Name: usb-storage 
Altermate Number: 0 
Class: O8(stor.) 
Sub Class: 6 
Protocol: 50 
Number of Endpoints: 2 


Endpoint Address: 81 
Direction: in 

Attribute: 2 

Type: Bulk 

Max Packet Size: 512 
Interval:; Oms 


Endpoint Address: 02 
Direction: out 
Attribute: 2 

Type: Bulk 

Max Packet Size: 512 
Interval: Oms 





Configure... About... 


(Close) 


2. kép Az usbview program és az általa szolgáltatott információk 


pet adtak vissza. A mai kijelzőket már valamennyire felké- 
szítették ennek a problémának a kezelésére, így használnak 
elmosást, de a tökéletestől még így is nagyon-nagyon 
messze állunk. 

Amennyiben a választható felbontások között nem találjuk 
azt a felbontást, amelyet a monitorunk tud, akkor még min- 
dig nincs minden veszve. Az /etc/X11/XF86Config-4 állo- 











mányban megpróbálhatjuk kézzel megadni a felbontást. 
Ezt a screen szekcióban tudjuk általában megadni. Álljon 
itt egy példa, az én gépem beállításai. Látszik, hogy a fel- 
bontások közé bekerült az 1400x1050-es felbontás. 


Section "Screen" 


Identifier "Default Screen" 
Device "Generic Video Card" 
Monitor "Generic Monitor" 
DefaultDpepth 24 
SubSection "Display" 

Depth 1 

Modes "1400x10507 


5 "1280x10247 "1280x9607 "1152x864" "1024x768" 
5" 800x6007 "640x480"7 
EndsubSection 
SubSection "Display" 
Depth 4 
Modes "1400x10507 
5 "1280x1024" "1280x9607 "1152x864" "1024x768" 
5" 800x6007 "640x480"7 
EndsubSection 
SubSection "Display" 
Depth 8 
Modes "1400x10507 
5 "1280x10247" "1280x9607 "1152x864" "1024x768" 
5" 800x6007 "640x480"7 


EndSubSection 
SubSection "Display" 
Depth 15 
Modes "1400x10507 


5 "1280x10247" "1280x9607 "1152x8647 "1024x768" 
5 "800x6007" "640x480"7 


EndsubSection 
SubSection "Display" 
Depth 16 
Modes "1400x10507 


5 "1280x10247" "1280x9607 "1152x8647 "1024x768" 
5 "800x6007 "640x480"7 


EndSsubSection 
SubSection "Display" 
Depth 24 
Modes "1400x10507 


5 "1280x1024" "1280x9607 "1152x864" "1024x768" 
5" 800x6007 "640x480"7 

EndSubSection 
EndSection 


Ha végeztünk a beállításokkal, akkor indítsuk újra az X-et 
(például a CTRL--ALT-- BACKSPACE billentyűkombinációval) és 
amennyiben elindul az X hiba nélkül, akkor legyünk na- 
gyon boldogok. Amennyiben nem, akkor megint érdemes 

a nethez fordulni. Nézzünk körül a tuxmobile.org-on, vagy 
a különböző fórumokban, hogy másoknak milyen tapaszta- 
latai vannak az adott modellel. 


OpenGL 


A következő probléma a videókártyámmal az volt, hogy az 
X-hez adott Radeon meghajtó úgy tűnt mintha nem akarta 
volna támogatni a hardveres OpenGL gyorsítást. Így min- 
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den OpenGL-es programom enyhén szólva lassú volt. 

Kis keresgetés a neten és világossá vált számomra, hogy 

a meghajtó amit használok valóban nem támogatja a hard- 
veres OpenGL-t. továbbá a grafikus eszközök gyártói a mo- 
bil eszközökbe épített lapkák terméktámogatását általában 
az adott eszköz forgalmazójára hárítják, sajnos azonban 
ezek a forgalmazók pedig nem igazán nyújtanak támoga- 
tást a Linuxhoz. Már kezdtem szomorkodni, hogy a Radeon 
7500 Mobility kártyámmal sikerült rossz lóra tennem, de 
aztán jött a reménysugár. Úgy hívják, hogy xserver-xfree86- 
dri-trunk. Ezt a csomagot kell feltennünk és beállítanunk, 
hogy kihasználhassuk a kártyánk nyújtotta 3D gyorsítási 
lehetőségeket. A csomag nincs benne a szokásos Debian 
forrásban, így a forráslistánkat ki kell egészítenünk a 


deb http: //dri . freedesktop. org/-daenzer/debian/ 
s dri-trunk-sid/ ./ 


sorral. Ezután jöhet az 
apt-get update 


és telepíthetjük is a csomagot. 

A telepítés folyamán a csomag beállításra is kerül, így sok 
teendőnk nincs vele. Amennyiben mégis problémánk me- 
rülne fel, akkor olvassuk el a /usr/share/doc/xserver-xfree86- 
dri-trunk könyvtárban található leírást. 

Ha beállítottuk, akkor a glxgears nevű programmal tesztel- 
hetjük a kártyát. Ez a program frissítési értékeket számol, 
így az FPS (frame/second) vadászok rögtön tudni fogják mit 
bír a kártya az adott felbontással. Aki pedig élesben is ki- 
próbálná a kártyát, annak ajánlom a tuxracer nevű játékot. 
Itt szeretném megjegyezni, hogy az Nvidia és az új ATI kár- 
tyákhoz már letölthető a gyári meghajtóprogram a gyártók 
weboldaláról. Ezekkel a meghajtókkal tapasztalataim sze- 
rint nem szokott semmilyen probléma előfordulni a 3D 
gyorsítás terén. 


TV és külső monitor kimenetek kezelése 

A mobil eszközökbe a múltban és jelenleg is előszeretettel 
használnak a gyártók ATI grafikus processzorokat. Régeb- 
ben a Rage, újabban a Radeon lapkák a népszerűek. Ezek 

a kártyák minden esetben tartalmaznak külső monitor csat- 
lakozót és a többségükön már a TV kimenet is megtalálha- 
tó. Ahhoz, hogy ezeket a kimeneteket használni tudjuk, 
szükség lehet arra, hogy egy külső alkalmazás segítségével 
engedélyezzük és beállítsuk őket. TV kimenet esetén példá- 
ul szükség lehet a használni kívánt TV szabvány beállításá- 
ra. ATI kártyák esetén egy ügyes kis alkalmazás erre a célra 
az atitvout csomag tartalma. Miután telepítettük a progra- 
mot az atitvout paranccsal tudjuk futtatni. A parancs beírá- 
sa után kapunk egy rövid használati utasítást, amelyben le 
van írva, hogy miként tudjuk az egyes kijelzőket, illetve 
azok csoportjait aktiválni, vagy kikapcsolni, miként tudjuk 
a TV kimenetet életre kelteni és a szabványt beállítani. 
Megjegyezném azonban, hogy a program sajnos nem száz 
százalékosan működik, az én ATI Mobility Radeon 7500-as 
kártyám S-Video kimenetét ugyanis nem sikerült vele beállí- 
tani, ugyanakkor ugyanezen 7500-as kártya kompozit kime- 
netes változata minden probléma nélkül beállítható. 
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3. kép A gscanbus felhasználói felülete 


Ugyan a TV kimenetem még nem működik, de a külső mo- 
nitor csatlakozó elsőre működött, nem is akárhogy. A gé- 
pem kijelzője egy 1400x1050-es TFT panel és a külső csatla- 
kozóra egy 1280x1024-es TFT-t kötöttem rá. És ami az X 
indítása után történt, az meglepett. Windows alatt egy ilyen 
helyzetben a kisebbik képernyőn az asztal területe nem fér 
el, így az egeret mozgatva az asztalon a kép csúszkál ide- 
oda, attól függően, hogy az asztal melyik területén tartóz- 
kodom. X alatt pedig az 1400x1050-es méretű asztalom 

egy huszárvágással le lett kicsinyítve 1280x1024-re. Ez alatt 
azt kell érteni, hogy a notebookom kijelzője továbbra is 
1400x1050-es felbontással üzemelt, míg a külső TFT monitor 
úgy működött 1280x1024-es felbontásban, hogy közben 

a teljes munkafelületem látszott a képen. Ugyan nem 

volt penge éles a kép, de teljesen használható volt. Ennek 
igazából akkor vehetjük hasznát, ha egy projektort kötünk 
a kimenetre, ugyanis anélkül, hogy állítgatni kéne a fel- 
bontást tudunk rendes képet vetíteni. Ismét le a kalappal 

a Linux előtt. 

A notebook gyártók által előszeretettel használt másik grafi- 
kus lapka az Intel Extreme chipset. Ahhoz, hogy ezeken 

a grafikus kártyákon engedélyezzük a külső monitor kime- 
netet az iöl0switch csomagra lesz szükségünk. Ha telepítet- 
tük, akkor az ig10rotate paranccsal tudjuk kapcsolni, 
hogy melyik kijelző legyen aktív. A három lehetőség a csak 
LCD, LCD és CRT, csak CRT. Ezeken a variációkon tudunk 
lépkedni a parancs futtatásával. Amennyiben ezt a paran- 
csot hozzárendeljük az FN-t-F5 kombinációhoz (lásd 

a Gyorsbillentyűk beállítása című részt), akkor a Windows- 
os működéshez teljesen hasonló működést kaphatunk. 


A touchpad beállítása 

Miután telepítettük a gépünkre az X-et és valamilyen ab- 
lakkezelő rendszert, boldogan indítjuk is a grafikus felüle- 
tet, ám hamar ismét üröm vegyülhet örömünkbe. Hozzá- 
érünk az egérhez, amire az elkezd össze-vissza ugrálni, 
teljesen értelmetlenül kattintgat, hol a bal, hol a jobb 
gombbal. A probléma abból adódik, hogy a tapipad kicsit 
más protokoll szerint adja a jelet a gépnek, mint a szab- 
vány PS/2, InPS/2 egerek. A megoldás? Természetesen 
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telepíteni kell a megfelelő csomagot az X-hez és elvégezni 
a beállításokat a már említett XFS6GConfig-4 állományban. 
Először tehát telepítsük a xfree86-driver-synaptics csomagot, 
majd az /usr/share/doc/xfree86-driver-synaptics könyvtárban 
található README. Debian állományban található példa 
alapján készítsük el a beállításainkat az XFS6Config-4 állo- 
mányban. Én az alábbi beállítást használom: 


Section "InputDevice"Section "InputDevice" 


Driver "synaptics" 
Identifier "Touchpad" 
option "CorePointer" 
option "Device" 
"/dev/psaux" 
option "Protocol" "auto-dev" 
option "LeftEdge" "1700" 
option "RightEdge" "53007 
option "TopEdge" STZO0T 
option "BottomEdge" "42007 
option "FingerLow" SZD" 
option "FingerHigh" 5307 
Option "MaxTapTime" "1807 
option "MaxTapMove" "2207 
option "vVertscrollDelta" "1007 
option "MinSpeed" "0.06" 
Option "MaxSpeed" 50.12" 
option "AccelFactor" "0.0010"7 
EndSection 


Fontos, hogy ne felejtsük el a Touchpad eszközt betölteni 
a ServerLayout szekcióban. Ez az alábbi példa alapján 
tehető meg: 


Section "ServerLayout" 
Identifier 
Screen 
InputDevice 
InputDevice 
InputDevice 
EndSection 


"Default Layout" 
"Default Screen" 
"Generic Keyboard" 
"Touchpad" 
"Generic Mouse" 


Fenti beállítással a tapipadunkat beállítottuk, méghozzá 
nem is akárhogy. A pad jobboldali szélén húzva ujjunkat 
görgethetjük az ablakot fel, illetve le, ugyanezt az alsó szé- 
lén csinálva horizontális gördítést csinálhatunk. Normál bal 
klikket egy ujjal ütve tudunk csinálni, középső gomb két 
ujj, jobb klikk három ujj. A pad sarkaiba tapintva további 
funkciók érhetők el. A jobb alsó sarok szintén jobb klikk, 
míg a bal felső kijelölt szövegre vonatkozó beillesztés 
művelet. 


Gyorsbillentyűk beállítása 

A mai notebookok szinte mindegyikén találhatóak már 
különböző gyorsbillentyűk, amelyeket felprogramozva 
gombnyomásra indíthatjuk a kedvenc böngésző és levele- 
zőprogramunkat, bekapcsolhatjuk a vezeték nélküli hálóza- 
ti kártyát, vagy elindíthatjuk a CD lejátszást. Ahhoz, hogy 
ezeket a jópofa funkciókat kihasználhassuk több beállítási 
mód közül is választhatunk. Elsőként az okosabb ablakke- 
zelők, mint amilyen a Gnome2, vagy a KDE már tartalmaz- 











nak beépített kezelői felületet ezeknek a funkcióknak 

a megvalósítására. Gnome 2.6 alatt a forróbillentyűk beállí- 
tásainál bizonyos funkciókhoz hozzá tudjuk rendelni nem 
csak a különböző billentyűkombinációkat, hanem ezeket 

az extra gombokat is. 

Másfelől bizonyos alkalmazások tartalmaznak olyan beépü- 
lő elemeket, bővítményeket, amelyek szintén lehetővé te- 
szik ezen gombok használatát. Ilyen például az XMMS-hez 
tartozó XFő6CAudio Keys Control plug-in. 

Harmadik és talán a leguniverzálisabb megoldás egy olyan 
felhasználói alkalmazás telepítése, amellyel ezekhez a bil- 
lentyűkhöz egyedi parancsokat tudunk rendelni. Ilyen al- 
kalmazást például az xhkeys csomag tartalmaz. Ha telepítet- 
tük a csomagot, akkor utána készíthetünk a teljes rendszer- 
re érvényes beállításokat, de készíthetünk felhasználónkén- 
ti egyedi beállításokat is. Mindezt úgy tehetjük meg, hogy 
futtassuk az xhkconf parancsot, üssünk le egy billentyűt, 
amelyhez funkciót kívánunk társítani, majd után adjuk 
meg, hogy milyen eseményt szeretnénk a billentyűhöz tár- 
sítani. Ez lehet egy alkalmazás indítása, egy belső funkció 
elérése, egy billentyűzet, vagy egér esemény. Ha befejeztük 
a billentyűk beállítását, akkor hagyjuk kicsit magára a prog- 
ramot, ugyanis a konfigurációk elmentése és a beállítás be- 
fejezése akkor történik meg, ha tíz másodpercig nem nyú- 
lunk a billentyűzethez. Ha végeztünk a beállításokkal, ak- 
kor futtassuk az xhkeys parancsot, ezzel aktiválva a beállítá- 
sainkat. Ha azt szeretnénk, hogy a grafikus felület minden 
indításánál automatikusan induljon a forróbillentyű keze- 
lőnk is, akkor érdemes az X folyamatba (session) elmenteni. 


A következő három bekezdésben megnézzük, hogy milyen 
grafikus felügyeleti megoldások vannak a PCMCIA kártyák, 
illetve a géphez csatlakoztatott USB és FireWire eszközökhöz. 


A PCMCIA kártyák felügyelete 

Amennyiben a gép telepítésekor nem töröltük a pcmcia-cs 
csomagot és a rendszermagban a támogatás is engedélyez- 
ve van a PC-kártyákhoz, akkor nincs különösebb teendőnk 
a PCMCIA kártyák működésre bírásához. Amennyiben bár- 
melyik fenti feltétel nem teljesül, akkor végezzük el a szük- 
séges beállításokat, telepítsük a pcmcia-cs csomagot. 

Ha ezzel megvagyunk, akkor dugjunk be egy kártyát a csat- 
lakozóba. A cardct1 parancsot megfelelően paraméterezve 
konzol alól tudjuk kezelni a kártyákat. Amennyiben ugyan- 
ezt a munkát egy szép grafikus programból szeretnénk elvé- 
gezni, akkor használjuk a cardinfo nevű programot. Ezt 

a programot indítva egy aranyos kis grafikus programot 
tudunk futtatni, amellyel alapinformációkat kaphatunk az 
egyes nyílásokba helyezett kártyákról, valamint kezelni tud- 
juk őket. A kártyákat fel tudjuk függeszteni, visszatölteni, 
vagy éppen eltávolítani a rendszerből. Ez azért lehet fontos, 
mert egy olyan kártyának az eltávolítása, amelyet a rendszer 
még nem engedett el könnyen kernel pánikhoz vezethet. 
Azok, akik rendelkeznek PCMCIA felületű kártyaolvasóval, 
adapterrel, azok nagy hasznát vehetik annak, hogy Linux 
alatt a megfelelő rendszermagmodul betöltése esetén 

a PCMCIA foglalatba helyezett memóriakártyák szabvány 
IDE eszközként kezelhetőek. Ehhez mindössze a rendszer- 
mag beállításainál a Device Drivers/ATA-ATAPI Devices/ 
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Physical ID: 0 
Link active: Yes 

Gap Count. 63 

IPHY Speed: 5100 

IPHY Delay: cz144ns 

IRM Capable: ves 

Power Class: None 

Port 0: Connected to parent node 
init. reset: No 


ÍNr. Textual Leafes: 1 
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4. kép A gscanbus által szolgáltatott információk 


PCMCIA ATA Support modult kell a rendszermagba fordí- 
tani. Utána betoljuk a kártyát a helyére és a cardinfo rög- 
tön meg is mondja, hogy melyik /dev eszközként tudjuk 
becsatolni a meghajtót. 


Az USB csatlakozók és eszközök felügyelete 
Megfelelően beállított rendszermag esetén az LISB-re kötött 
különböző eszközök elvileg azonnal használhatóvá válnak, 
a csatlakozási felületük megjelenik a /dev/usb könyvtárban, 
az eszközök listázhatóak az Isusb paranccsal. Ha szeret- 
nénk egy látványos topológiát is megjeleníteni, valamint to- 
vábbi információkra is szükségünk lenne az USB-s periféri- 
ákkal kapcsolatban, akkor használjuk az usbview csomag 
usbview parancsát. Ezzel egy egyszerű grafikus alkalmazást 
indítunk el, amely megjeleníti a teljes UISB fát, amely a gé- 
pünkhöz kapcsolódik. Az egyes eszközöket kijelölve a jobb- 
oldali ablakban olyan fontos információk jeleníthetőek meg, 
mint az eszköz által foglalt sávszélesség, az USB csatlakozás 
sebessége, a gyártó neve, a pontos modellszám. Ezek na- 
gyon hasznos információk lehetnek egyfelől a lehető legha- 
tékonyabb erőforráskihasználás eléréséhez, másfelől hiba- 
keresés, vagy meghajtó program telepítésekor is nagy hasz- 
nát vehetjük ezeknek az információknak. 

Notebookok esetén sokszor felmerül az igény, hogy USB-re 
különböző külső meghajtókat csatlakoztassunk. Ezt 
könnyen megtehetjük, ha a rendszermagban engedélyez- 
zük az USB Storage Support modult. Ezzel a modullal egy- 
szerűen csatlakoztathatunk különböző kártyaolvasókat, 
USB-s memóriakártyákat. Egyszerűen csak összedugjuk az 
eszközöket és már csatolhatjuk is be a meghajtót. 

Kissé más a helyzet, ha LISB-re csatolt CD, vagy DVD írót 
szeretnénk használni. Itt is fordítsuk a rendszermagba az 
USB Storage Support modult, de emellett még szükségünk 
lesz az ATA-ATAPI eszközök beállításai között található 
SCSI Emulation Support modulra, valamint a SCSI eszközök 
között SCSI generic és CDROM support modulokra. Ezután 
a CD, DVD írónkat csatlakoztatva az eszközt a /dev/srX alatt 
találjuk, ahol X egy 0, vagy annál nagyobb szám, attól füg- 
gően, hogy hány eszközt csatlakoztattunk. 
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Én személy szerint a külső merevlemezeket is a SCSI illesz- 
tésen keresztül szoktam csatolni, így a kernelben még hoz- 
záadom a SCSI disk support modult is a rendszermaghoz. 
Ezután az USB-n becsatolt lemezek a /dev/sdXY eszközön 
keresztül érhetőek el, ahol X egy a..z közötti karakter, Y egy 
1..n szám, attól függően, hogy hányadik lemez, hányadik 
partíciójáról beszélünk. 

Annyit még érdemes tudni az LISB eszközökről, hogy mint 
az a csatoló nevében is benne van, ezek sorosan kötött esz- 
közök. Ennek a ténynek komoly jelentősége lehet, ha több 
olyan eszközt kapcsolunk össze, amelyek nagy sávszélessé- 
get igényelnek, hiszen ilyenkor rossz esetben a sebesség 
drasztikusan visszaeshet. Ez pedig egy videókamera, vagy 
egy DVD-író esetében nem éppen jó dolog. 

Ennek kiküszöbölésére érdemes ilyen eszközök esetén 
USB 2.0-s csatolót használni, ami az 1.1-es 12 Mbit/sec 
sebességéhez képest több 400 Mbit/sec-os átviteli sebességre 
képes. Ilyen átviteli sebesség mellett már nyugodtan hasz- 
nálhatunk olyan sávszélességzabáló eszközöket is, mint 

a már említett DVD-író, külső merevlemez, vagy sokcsa- 
tornás hangkártyák. 


FireWire, a tüzes vezeték 

A másik olyan eszköz, amelyet kifejezetten olyan eszközök- 
höz terveztek, amelyekhez nélkülözhetetlen a nagy sebes- 
ségű kapcsolat, az akár 400 Mbit/sec sebességre képes 
FireWire, vagy IEEE1394-es szabványú csatoló. 

A legújabb notebookok nagyobb hányadán már található 
FireWire csatoló, amelyen keresztül különböző nagy sebes- 
ségű eszközöket — például videókamerákat, merevlemeze- 
ket — köthetünk a számítógépünkhöz. (Itt jegyezném meg, 
hogy a FireWire csatolók használhatóak hálózati eszköz- 
kéntis, de erről majd talán egy későbbi cikkben lesz szó.) 
Természetesen a FireWire eszközök csatolásának első lépése 
itt is a megfelelő modulok befoglalása a rendszermagba. Az 
IEEE 1394 (FireWire) support menüpont alatt található mo- 
dulok közül a videókamerák életrekeltéséhez az alábbi mo- 
dulokat szoktam használni: OHCI-1394 support, OHCI-1394 
Video support, OHCI-DV I/O support, Raw IEEE1394 I/O 
support. Amennyiben merevlemezt szeretnénk FireWire-n 
keresztül elérni, akkor szükségünk lesz a SBP-2 support 
(Harddisks etc.) modulra, valamint a DMA kihasználásához 
a Enable Phys DMA support for SBP2 modul bejelölésére. 
Ha elkészültek a modulok, vagy újraindultunk a friss rend- 
szermaggal, akkor telepítsük fel a gscanbus csomagot, 
amely egy az usbview-hoz hasonló funkciójú programot 
tartalmaz. A gscanbus indítása után szintén grafikus felü- 
leten rögtön megkapjuk a gépünkhöz csatolt FireWire esz- 
va bővebb információkat kaphatunk az adott eszközről. 

A videókamerám esetében például arra is lehetőség van, 
hogy a számítógépről vezéreljem annak működését. 

Ezzel cikkem végére is értünk volna. Úgy gondolom, 
mostis sok hasznos eszközzel és beállítással ismerked- 
tünk meg. Mindenkit arra buzdítanék, hogy játszadozzon 
el a közelében fellelhető ilyen eszközökkel, próbálgassa 

a beállításokat, ugyanis sok érdekességet tartogat szá- 
munkra a Linux. 


Illés Viktor 











A felhasználói viselkedés vizsgálata 42. rész) 


A sorozat előző részében megismerkedtünk a digitális Nagy Testvér módszerei- 
nek elméleti lehetőségeivel. Tudjuk tehát, hogy mit és miért lehet és érdemes 


megvalósítani. Most lássuk hogy hogyan! 


Adatgyűjtés általában 

Az internet, azon belül is a weblapok hálózata folyamato- 
san, és megdöbbentő mértékben növekszik, akár a forgal- 
mat, akár a weboldalak összetettségét és számát vizsgáljuk. 
Ezzel a folytonos növekedéssel természetesen a webolda- 
lakon látható grafikának, a webkiszolgálók tervezésének, 
kialakításának, méretezhetőségének is lépést kell tartania. 
Nem kivétel ez alól a weboldalakon belüli navigáció össze- 
tettsége sem, éppen ezért a webes fejlesztési folyamatok 
egyik legfontosabb ,bemenő paramétere" a weboldal hasz- 
nálatának jellemzése. 

A weben elérhető információ mennyisége és szerkezeti 
összetettsége már régóta tökéletesen lehetetlenné teszi, 
hogy a hely pontos ismerete nélkül, egyszerűen csak meg- 
találjuk azt, amit éppen keresünk. Ezt felismerve kezdték el 
fejleszteni az adatbányászat (data mining) mintájára a , web 
mining" módszereket. A web mining szolgál az interneten 
fellelhető hasznos információ felfedezésére, elemzésére és 
kategorizálására. A web miningnak nevezett tevékenység 
tulajdonképpen maga is három fő részterületre osztható: 


e — Tartalom (Content Data): a felhasználónak jelentéssel 
bíró adatok elemzése. A , Web Content Mining" az 
a folyamat, amely során a webes dokumentumokból 
skiemeljük" a tényleges tudást. 

e — Szerkezet (Structure Data): azoknak a metaadatoknak 
az összessége, amelyek meghatározzák egy szervezet 
webes információs rendszerének logikai struktúráját. 
A , Web Structure Mining" során a tudást (információt) 
tehát az adott honlap szerkezete hordozza. 

e Használat (Lsage Data): olyan adat, amely a felhaszná- 
lók webes interakciói során keletkezik. A , Web Usage 
Mining" célja az, hogy szabályosságokat fedezzen fel 
a felhasználók viselkedésében, lépéseiben, vagy például 
abban, hogy mit töltenek le. 


A szakirodalom a felhasználói viselkedés vizsgálatát , Web 
Usage Mining", míg a modellezéshez szükséges adatok elő- 
állítását , Usage Mining" néven említi. 

Amint azt az előző részben már említette, a viselkedés mo- 
dellezése alapvetően két részből áll: az adatgyűjtésből és az 
adatok elemzéséből. A gyűjtés feladata olyan adatok előállí- 
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tása, amelyek megfelelően részletesek ahhoz, hogy az analí- 
zist végző szoftverek használható modelleket alkothassanak 
belőlük. Mivel nem célunk az, hogy minden egyes látogató 
viselkedését egyenként elemezzük, csupán az , átlagos láto- 
gató" paramétereire vagyunk kíváncsiak, ezért a megsze- 
mélyesítést lehetővé tevő adatokra (tipikusan IP cím és fel- 
használónév) csak a felhasználói munkamenetek elkülöní- 
téséhez van szükségünk. 

Amennyiben a felhasználókat más módszerrel is meg lehet 
különböztetni (például rendelkeznek egyedi munkamenet 
azonosítóval), akkor semmilyen személyes adatra nem lesz 
szükségünk, hiszen elegendő az oldal neve és megtekinté- 
sének időbélyege. 

Az adatgyűjtési módszerek alapvetően három csoportra 
oszthatóak. A megfigyelést végző kódot beépíthetjük magá- 
ba az oldalba, illetve végezhetünk adatgyűjtést az ügyfélen 
és a kiszolgálón. Mint megannyi más területen, itt is mind- 
egyik módszernek megvannak a maga előnyei és hátrányai, 
amelyekkel tisztában kell lennünk, mielőtt alkalmazni kezd- 
jük őket. Lássuk tehát! 


Weboldalba épített adatgyűjtés 

A módszer lényege, hogy már a portál tervezésekor kiemelt 
figyelmet szentelünk annak, hogy a felhasználók tevékeny- 
ségéről megfelelő információval rendelkezzünk. Gyakori 
megoldás, hogy a weboldal elérése regisztrációhoz kötött, 
és csak a regisztrált és beléptetett felhasználók érhetik el 

a hasznos információt hordozó belső oldalakat. 

Ez a módszer komoly fejlesztési ráfordítást igényel, hiszen 
már a tervezést is számos ponton befolyásolja. 

Ha nem a kellő körültekintéssel járunk el, az később hátrá- 
nyosan befolyásolhatja a rendszer fejleszthetőségét, vagyis 
éppen azt, amiért az adatokat gyűjtjük, és a rendszer hasz- 
nálatát modellezzük. Hiába tudjuk az adatok alapján, hogy 
milyen szerkezeti változásokat kellene végrehajtanunk, ha 
a gondatlan tervezés miatt nem tudjuk azokat elvégezni. 
Az adatgyűjtést végző programkódok alig, vagy egyáltalán 
nem újrahasznosíthatóak, hiszen minden egyes weboldal 
felépítése — ha olykor igen csekély mértékben is de - eltérő. 
Ugyanakkor éppen azért, mert a kódot maga az oldal tartal- 
mazza, egészen pontos információkat kapunk külön-külön 
minden egyes felhasználó viselkedéséről. Ez még akkor is 
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igaz, ha az illető a regisztráció alkalmával valótlan adatokat 
adott meg. Ráadásul megfelelő kialakítás esetén ez a mód- 
szer képes rögtön előszűrt adatokkal ellátni az analizálást 
később elvégző alrendszert. 

A regisztráció és belépési kötelezettség azonban egyrészt el- 
riaszthatja az anonimitásukat megőrizni igyekvő felhaszná- 
lókat. A legtöbb ember a magánszférába való túlzott beha- 
tolásként értékeli az ilyen jellegű működést, illetve zavarja 
az a tudat, hogy egy lelketlen rendszer minden lépését fi- 
gyeli. Megjegyzendő persze, hogy a portál megfelelő tarta- 
lommal ellensúlyozhatja a magánszférába való behatolást. 
A magánszféra megsértésének problémáját ki lehet küszö- 
bölni úgy is, ha nem az egyes felhasználók műveleteinek 
sorozatát mentjük, hanem csak azt, hogy a felhasználóink 
mit csináltak a portálon belül. Ilyenkor az adatokat olyan 
formában tároljuk, hogy azokból eleve lehetetlen legyen 
megmondani mondjuk azt, hogy személy szerint Teszt Ta- 
más merre barangolt az oldalak között. Természetesen eh- 
hez az egészhez az is fontos, hogy a látogatók valamelyest 
megbízzanak a portált működtető szervezetben, hiszen 

a programkódokba nem lát bele az egyszerű felhasználó. 
Nyílt forrású szoftverrel ez a probléma részben feloldható, 
de az adatvédelmi elvek betartásának ellenőrzése komoly 
programozási ismereteket igényelhet. 

Mint említettem, ennek a megoldásnak az is előnye lehet, 
hogy eleve szűrt adatokat szolgáltathat. Pontosan tudjuk 
naplózni, hogy mely weboldalt mikor kérték le, az ese- 
ménynapló közvetlenül feldolgozható és a munkamenetek 
elkülönítésével sem kell foglalkoznunk, mert a belépéskor 
minden egyes felhasználónak létrejön az egyedi munkame- 
net azonosítója. Mivel a weboldalt előállító program a ki- 
szolgálón fut, a módszer rendelkezik a szerver oldali adat- 
gyűjtés összes ismert hátrányával is. 


Adatgyűjtés az ügyfélen 

Az ügyfél oldalán történő adatgyűjtés megpróbálja (bizo- 
nyos tekintetben szinte teljes sikerrel) a HTTP protokoll és 
a web felépítéséből, működéséből adódó hátrányokat kikü- 
szöbölni. 

Az alapvető módszer az, hogy az ügyfélen egy a böngésző- 
től független program (esetleg annak egy kiegészítése, va- 
gyis egy ,plug-in") folyamatosan figyeli a felhasználó által 
végzett műveleteket: melyik weboldalt mikor kérte le, 
mennyi idő alatt érkezett meg az a kiszolgálóról, sőt akár az 
is mérhető, hogy az adott oldalt tartalmazó ablak mennyi 
ideig volt aktív. 

Ez a bizonyos kiegészítő program többféleképpen kerülhet 
az ügyfélhez. Lehetőség van arra, hogy a honlap letöltése- 
kor automatikusan betöltődjön és elinduljon a kliens böngé- 
szőjében úgynevezett beágyazott HTML objektumként. 
(Ilyen például egy JAVA applet, egy Flash, vagy egy ActiveX 
komponens.) Biztonsági okokból ez a megoldás csak korláto- 
zottan használható. Az így letöltött program csak az adott 
(ahonnan letöltötték) kiszolgálóval tud kommunikálni, és 
nem képes a helyi géppel adatokat cserélni, hiszen csak ide- 
iglenes fájlokat tud létrehozni, amelyek a portál elhagyása- 
kor, de legkésőbb a böngésző bezárásakor megsemmisülnek. 
További probléma, hogy csak annak a portálnak a tartalmá- 
val kapcsolatban működőképes, ahonnan letöltötte a fel- 
használó. Utóbbi probléma részben kiküszöbölhető azzal, ha 
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minden weboldalról letöltődik a program és egy közös he- 
lyen (például egy sütiben) tárolják a munkamenet azonosí- 
tót. További, nem elhanyagolható hátrány, hogy a sütikhez 
hasonlóan ez a lehetőség is letiltható a böngészőben. 

Egy másik lehetőség az, ha egy a böngészőtől független, 
harmadik szoftver segítségével figyeljük a felhasználó 
webes műveleteit. Ekkor lehet a legpontosabb adatokat 
összegyűjteni, hiszen ez a harmadik, kiegészítő szoftver ké- 
pes a böngészés előtt, alatt és után is rögzíteni a történése- 
ket. Pontos adatokat kaphatunk a hálózati átviteli időkről, 
az egyes weboldalak olvasásának idejéről, megfigyelhető és 
mérhető a lokális és távoli átmeneti tárak (proxy kiszolgá- 
lók) hatása. Előny, hogy az így keletkező adatokat a későb- 
biek során nem kell előfeldolgozni sem. 

Mindkét esetben szükséges, hogy a harmadik, kiegészítő 
program teljesítményigénye minimális legyen, hiszen ellen- 
kező esetben a felhasználó hamarabb elhagyja a portált 
mert az lassú, illetve törli a programot a számítógépéről. 

A módszer legnagyobb hátránya, hogy felhasználói aktivi- 
tást követel meg: magának a felhasználónak kell telepítenie 
és beállítania a szoftvert. További nehézség, hogy a felhasz- 
nálók többségének nem fűződik érdeke az ilyen jellegű 
programok használatához, sőt egyre jellemzőbb a kifejezett 
elzárkózás. 

Az ilyen programok általában nem szabványos protokollon 
és portokon keresztül juttatják vissza az összegyűjtött ada- 
tokat a kiértékelést végző rendszerhez, ezért könnyen elő- 
fordulhat, hogy mind az egyéni, mind a vállalati szférában 
egyre gyakoribb proxy és tűzfal megoldások nem engedik 
át az ilyen jellegű adatfolyamokat. Jellemző továbbá, hogy 
elsősorban vállalati környezetben a felhasználók jogosultsá- 
gai igen korlátozottak, ezért nem tudnak semmilyen szoft- 
ver telepíteni. 


Adatgyűjtés a kiszolgálón 

A kiszolgálón történő adatgyűjtés nem igényli az ügyfél 
együttműködését, így nincs szükség sem harmadik fél által írt 
programokra, sem a felhasználó hozzáértésére és hozzájáru- 
lására. A felhasználó megkímélhető a regisztrációtól is, mert 
az eseménynapló a portáltól független módon keletkezik. 

A szerver oldali adatgyűjtés tulajdonképpen nem más, mint 
az általában amúgy is működő naplózó szolgáltatás (hiba- 
keresés, teljesítmény analízis, behatolási kísérletek felderíté- 
se) kiterjesztése a tárolt speciális paraméterekkel (böngésző 
típusa, előző oldal (referer), munkamenet azonosító). Az így 
keletkező adatsor nem alkalmas arra, hogy valós időben 
szolgáljon adatokkal a modellezéshez, hiszen jelentős , tisz- 
títást" igényel éppen a szerteágazó adattartalom miatt. 

A módszer hátrányai a HTIP protokoll és a világháló mű- 
ködéséből adódnak. 

A felhasználók minél gyorsabban szeretnék letölteni a tar- 
talmat, a vállalatok viszont igyekeznek spórolni a kommu- 
nikációs költségekkel, illetve egyes tartalmakat szűrni akar- 
nak. (Munkaidőben például ne magánjellegű információk 
keresésével töltse az idejét a munkavállaló.), Éppen ezért 
használnak annyian átmeneti tárakat és különböző proxy 
technikákat. 

A modern böngészőprogramok azzal is segítik a felhaszná- 
lót, hogy az egyszer már letöltött weboldalakat tárolják. 
Előfordulhat akár az is, hogy a felhasználó a weboldalba 











épített navigációs elemeket használja (linkekre kattint) és 
nem a böngésző wissza" és ,előre" gombjait, az esemény- 
naplóban mégsem jelenik meg a bejegyzés, mert a böngé- 
sző szoftvere észleli, hogy letöltött honlapról van szó és 

a lokális átmeneti tárból szolgálja ki a kérést. 

Az ilyen , zajok" kiszűrése nem lehetséges pusztán az ese- 
ménynapló feldolgozásával. A zaj jellege és mérete nem be- 
csülhető, hiszen az ügyfélen végzett adatgyűjtéstől eltérően 
itt nem áll rendelkezésre pontos adat a tényleges lekérések- 
ről. A probléma ugyanakkor részben áthidalható 

a webszerver beállításával. A HTTP protokoll lehetőséget 
ad arra, hogy az átküldött fejlécben jelezzük: nem akarjuk, 
hogy a kérdéses weboldal a lokális tárba kerüljön. Ilyenkor 
a böngésző ugyan minden alkalommal újra lekéri azt, 
ugyanakkor elvesznek a lokális és távoli átmeneti tárak, 
illetve proxy kiszolgálók által nyújtott előnyök. 

A fentiek miatt a kérések egy meghatározhatatlan része el 
sem jut a webkiszolgálóig, jelentősen rontva ezzel a mód- 
szer pontosságát. Ugyanakkor az átmeneti tárakban leg- 
gyakrabban a képek tárolódnak, amelyek a viselkedés mo- 
dellezés során nem (feltétlenül) jelentenek értékes informá- 
ciót. Mindent egybevetve a legjobb megoldás talán a három 
módszer valamiféle összeházasítása lehetne. 

A kiszolgálón történő adatgyűjtés egy másik jellegzetes 
problémája a nem determinisztikus hálózati működés. Ez 
azt jelenti, hogy egy az eseménynaplóba bekerült felhasz- 
nálói kérés jelenléte nem jelenti teljes biztonsággal azt, 
hogy a felhasználóhoz el is jutott a kért tartalom. Akár az is 
lehetséges, hogy a letöltés befejeződése előtt a felhasználó 
bezárta a böngészőt, hiszen a webkiszolgáló erről nem kap 
visszajelzést. Tekintettel a mai hálózatok viszonylagos meg- 
bízhatóságára az így keletkező zaj csak kis jelentőséggel bír. 
Az eseménynaplóba minden a kiszolgálóhoz érkező kérés 
bekerül: minden lekért dokumentumnak, képnek, videó- 
nak, zenének, animációnak, appletnek, vagy fájlnak nyoma 
van. Ez azt jelenti, hogy egy-egy weboldal letöltésével akár 
több tíz bejegyzés is keletkezhet. Ugyanakkor a modellezés 
szempontjából lényeges információt csak bizonyos elemek- 
kel kapcsolatos bejegyzések hordoznak. Ezért az esemény- 
naplót a portál szerkezetének (vagy a kívánt modellnek) 
megfelelő előfeldolgozás során ,meg kell szűrni". 

A modern portálfejlesztés bevált módszere, hogy a külön- 
böző weboldalakat egyetlen fájl készíti el paraméterektől 
(esetleg amunkamenetben tárolt adatoktól) függően. Ekkor 
bár a felhasználó folyamatosan egy bizonyos weblapot kér 
le, a tartalom mindig más. A modellezés során ugyanakkor 
nyilván el kell különíteni ezeket a lekéréseket, hiszen tartal- 
milag különböző weboldalaknak tekintendők. Az előfel- 
dolgozás során az eseménynapló lekérések mezőjének vizs- 
gálatával lehet elkülöníteni a formailag azonos fájlhoz tar- 
tozó, de tartalmilag különböző lekéréseket. 

A POST metódussal átadott és a munkamenetben tárolt 
paraméterek esetén újabb problémával szembesülünk. 

Az ilyen lekérések sajnos nem kerülnek be az eseménynap- 
lóba és általánosan használható módszerek sincsenek 

a mentésükre. Nem is szokás tárolni ezeket a kéréseket, 
hiszen egy-egy ilyen kérés mérete akár több megabájt is 
lehet, ami egy komoly forgalmú portálnál a tartalomnál 
akár négy-nyolc nagyságrenddel nagyobb méretű ese- 
ménynaplót eredményezne. 
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Mindez ugyanakkor igazi problémát csak akkor jelent, ha 
a POST illetve munkamenet adatok ugyanarra az oldalra 
kerülnek vissza rendszeresen, mint ahonnan elindították 

a kérést. Egyre több szakember van azon a véleményen, 
hogy egy URI-nak könnyen olvashatónak és érthetőnek 
kell lennie, vagyis legalább körülbelül ki kell derülnie belő- 
le, hogy mi található az adott weboldalon. 

Régóta biztosítják a webszerverek a kérések átírásának le- 
hetőségét, amellyel így részben elfedhetők a POST és GET 
metódus miatti azonos lekérések. 


Ha pédául a 


http: //ww. ceg. hu/index . php?m-Ogsub-1gc id-2€r id-3 
5 gact-5 


forma helyett a 


http: //ww. ceg.hu/szolgaltatasok/hardverfejlesztes/ 
s ajanlat 


formát használjuk, akkor az átalakítást a webszerver végzi 
a megfelelő beállítások szerint. Az ilyen úgynevezett , barát- 
ságos linkek" nagyban megkönnyítik a felhasználói viselke- 
dés modellezését, mert az eseménynaplóban egyértelműen 
és könnyen szétválogatható módon jelennek meg a vizsgá- 
landó elemek. 

Az előfeldolgozás sajnos jelentős többletterhelést jelent 

a modellkészítés során, így ez a módszer nem alkalmas ar- 
ra, hogy online, azaz folyamatosan frissülő statisztikákat és 
modelleket szolgáltasson. Tipikus megoldás, hogy a feldol- 
gozás és modellalkotás a portál legkevésbé terhelt időszaká- 
ban napi rendszerességel zajlik (általában éjszaka). 

A modellezés során a legnehezebb feladat az egyes fel- 
használók elkülönítése. Az eseménynapló alapesetben 
nem tartalmaz ehhez elégséges információt, mert a proxy 
és tűzfal mögül érkező látogatók adatai szinte teljesen 
megegyeznek. Egyes webszerverekhez már létezik olyan 
kiegészítő modul, amely munkamenet azonosítót rendel 
minden felhasználóhoz. Használható ezen kívül idő alapú 
elkülönítés, user agent vizsgálat, illetve a referer és lekéré- 
sek közötti folyamatosság vizsgálata a portál szerkezeté- 
nek ismeretében. 

A módszer előnye, hogy sem hardveres sem szoftveres 
együttműködést nem igényel az ügyféltől. Csupán a sütik 
támogatása szükséges a munkamenet azonosító tárolásá- 
hoz, nem kell azonban sem az aktív felhasználói közremű- 
ködés, sem harmadik program vagy regisztráció. 
Adatvédelmi szempontból is kedvezőbb megoldás a már 
ismertetetteknél, ugyanis a felhasználó nem kerül olyan 
mértékben megszemélyesítésre, ami az a magánéletét túl- 
zottan sértené. A ma jellemző tűzfal, proxy és dinamikus 
IP cím kiosztási technikák tovább gyengítik a megszemé- 
lyesíthetőséget. Az eljárás egyedüli, ám igen lényeges hát- 
ránya, hogy a felhasználó tudta és beleegyezése nélkül is 
keletkeznek a tevékenységével kapcsolatos adatok. 
Következő cikkemben részletesen ismertetem a szükséges 
Apache modulokat, illetve azok beállításait. 


Beszédes Balázs 
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FreeBSD - a szomszéd vár 42. rész) 


Egy FreeBSD rendszer adminisztrációja és finomhangolása. 


zt hiszem egyet tudunk érteni, hogy két UNIX 
rendszer használata között nincs lényeges különb- 
ség. Azonos programokat tudunk azonos módon 


használni: lényeges különbségek leginkább a rendszergaz- 
da szemszögéből jelentkeznek. 


Rendszerindítás 

A FreeBSD kicsit másképp indul mint egy Linux rendszer, 
ugyanis csak egy egyszerűbb rendszerbetöltő modullal 
rendelkezik, amelynek alapvetően nem feladata más ope- 
rációs rendszerek elindítása. Ez annyit jelent, hogy csak 

a FreeBSD-t, illetve a DOS-t és a hozzá hasonlóan induló 

a Windows operációs rendszereket képes elindítani. Ezeknél 
a rendszereknél ugyanis egy úgynevezett boot szektort kell 
beolvasni, a rendszer elindítását már ez a kis program vég- 
zi. A jelenkori Linux rendszerek viszont ennél már egy ki- 
csit összetettebb indítást igényelnek, lévén pontosan meg 
kell határozni a gyökér-fájlrendszer elérését, esetleg egy 
initrd elindítása is szükséges lehet. Ez utóbbi feladatokat 

a FreeBSD rendszerindítója nem képes felvállalni. Ha meg- 
fordítjuk a helyzetet, akkor egy megfelelően telepített LILO 
vagy GRLUIB képes a FreeBSD-t elindítani: érdemes ezt a fel- 
adatot egy Linux rendszerre bízni. 


A nulladik fázis — MBR program 
Ha telepítettük a BootMgr programot, akkor a gépünket 
bekapcsolva a következő kép fogad bennünket: 


F1 FreeBSD 
F2 DOS 
F4 ?? 
Default: F1 


A BootMgr az adott partíció szerkezetének megfelelő szöve- 
get írja ki, ahol rendre a merevlemez partícióit láthatjuk. 
Amelyik partíció nem aktív, de létezik, ott kettő kérdőjelet 
láthatunk név helyett. 

A logikai partíciók nem látszanak, helyettük csak a kiter- 
jesztett partíció látható (szintén kettő kérdőjellel). Az alap- 
értelmezett mindig az utoljára használt operációs rendszer 
lesz, bizonyos idő elteltével ez el is fog indulni. A kívánt 
operációs rendszert a megnevezett funkcióbillentyűvel tud- 
juk kiválasztani. A BootMgr program másolata a /boot/boot0 
állományban található. 
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Az első fázis — Boot program 

A BootMgr (vagy egyéb hasonló) program betölti a partíció 
elején található úgynevezett boot szektort, amely a FreeBSD 
indításának első fázisát tartalmazza. Sok tevékenységet nem 
lehet belesűríteni, hiszen ennek a szektornak a mérete csak 
512 Bájt (/boot/boot1 fájl másolata); egyedüli dolga a beledró- 
tozott címről a második fázis programját beolvasni. 


Második fázis — Előtöltő program 

Az előtöltő program (BTX loader) veszi át a stafétabotot, 
amely közel 8 kilobájt méretű (/boot/boot2 állomány). 

Ez már elegendő méret arra, hogy a FreeBSD által használt 
UES (illetve LIFS2) fájlrendszert alapszinten kezelni tudja. 
Ki tudjuk választani a betöltendő rendszermagot és a be- 
töltő (Ioader) programot. Ezek általában a /boot/kernel és 

a /boot/loader állományban találhatók. Az előtöltő beolvas- 
sa a betöltő programot, majd elindítja azt. 


Harmadik fázis — Betöltő program 

A /boot/loader felel a rendszermag és a hozzá tartozó modu- 
lok betöltéséért. Ha saját rendszert fordítunk, ez a betöltő 
program együtt készül el az új rendszermaggal. Tartalmaz 
egy egyszerű parancsfelületet, ahol a tőbb paramétereket 
módosítani tudjuk. A betöltő program feldolgoz néhány 
szöveges állományt is, amelyekkel a betöltést befolyásolni 
tudjuk. Ilyenek a /boot/loader:rc, a /boot/defaults/loader.conf 
és a /boot/loader.conf. Ezekből a /boot/loader.conf állományt 
érdemes megnézni, ahol a betöltendő rendszermagmo- 
dulokat tudjuk megadni: 


ng ubt 10ad-7YES" 
Tinux 1o0ad-"YES" 
nvidia 10ad-"7YES" 


A rendszermag 

Az operációs rendszerek lelke az a mag, amely feladata tö- 
mören a gépben található hardverek, erőforrások és perifé- 
riák kezelése, illetve a programok biztonságos futtatása. 

A FreeBSD rendszermag fényes fehér szöveget ír ki a meg- 
talált eszközökről, illetve azok nevéről; s ez a szöveg akár 
két-három képernyőnyi is lehet. 


A rendszermag beállításai 
A telepítéssel foglalkozó részben kihagytam a rendszermag 
beállításait, mivel egy általánosságban munkaállomásnak 











használt telepítést nem befolyásol érdemlegesen. Ebben 

a részben viszont témába vág, s szeretném itt megemlíteni 
ezt a fontos műveletet. 

Legegyszerűbb (de nem egyedüli!) módja ennek a beállítás- 
nak, hogy a feltelepített rendszert újratelepítjük (zárójelben 
megjegyzem, hogy a FreeBSD működését jobban elsajátítva 
három-öt hét múlva egy újratelepítéssel sok előnyhöz jut- 
hatunk: másképp nézünk a fájlrendszer szerkezetére; eset- 
leg más programokat használunk, mint először gondoltuk; 
a feltett komponenseket közül esetleg mást választunk ki). 
A rendszermag beállításának lényege, hogy feloldjuk az üt- 
közéseket az egymással konfliktusba kerülő eszközmeghaj- 
tók között. Ehhez a tevékenységhez nagyon ismerni kell 

a gépünkben található hardvereszközöket és ezek pontos 
működési paramétereit (DMA, IO és IRO számok). A rend- 
szermag ugyan jó , hatásfokkal" képes a gépünkben találha- 
tó eszközöket helyesen beállítani, viszont előfordulhatnak 
olyan hibák, amelyekhez kevés lesz a tudása. Például 

a rendszermag olyan eszközöket is találni vélhet, amelyek 
nincsenek; olyan meghajtókat esetleg nem tudhat beállíta- 
ni, amelyek által kezelt hardverek viszont vannak a gé- 
pünkben. Ekkor le kell tiltanunk a nem használandó esz- 
közmeghajtókat, majd engedélyeznünk kell azokat, ame- 
lyeket ellenben használnánk. Egyre kevésbé előforduló 
probléma a PnP tudást mellőző (EJISA kártyák beállítása, 
amelyeknél pontosan meg kell adnunk a rendszermagnak 
a kártya által használt paramétereket. 

A rendszermag betöltésekor a betöltő program beolvassa 

a /boot/device.hints állományt, amely a fentieket tartalmazza 
szöveges formában: 


hint.fdc.0.at-"isa" 
hint.fdc.0.port-—"0x3FO" 
hint.fdc.0.irg-76" 
hint. fde.O0.drge"2 


Ennek az állománynak a szerkezete módosulhat a rendszer- 
mag fordításakor, lévén ha az egyes eszközmeghajtókat ki- 
hagyjuk vagy beletesszük az új rendszermagba, akkor érte- 
lemszerűen ezekhez tartozó device.hints sorok megszűn- 
nek vagy újak keletkeznek. 

A rendszermag betöltése után a /sbin/init program veszi át 
a vezérlést, amely elvégzi az operációs rendszer alapvető 
működéséhez szükséges programok betöltését és kezelését. 
Ekkor a kiírt a szöveg színe már világosszürke lesz. 


Az alaprendszer és a telepített programok beállításai 
A legtöbb beállítási igényünket a /etc/rc.conf állományban 
tehetjük a FreeBSD számára nyilvánvalóvá. Üres vagy 
majdnem üres /etc/rc.conf állomány esetén sem kell aggód- 
nunk, a legtöbb (alapértelmezett) beállítást a /etc/defaults/ 
rc.conf fájlban megtaláljuk, amelyeket a /etc/rc.conf beállítá- 
sai értelemszerűen felülbírálnak. A sysinstal1] program 
szintén ebbe az állományba írja az általunk választott beállí- 
tásokat, azonban ezek a beállítások csak egy újraindítás 
után lépnek életbe. Természetesen nem kell minden egyes 
változtatás után újraindítani az operációs rendszert, de kü- 
lönösebb tudás nélkül ez a leggyorsabb mód. 

Sok egyéb lehetőségünk is van a /etc/ könyvtárban, ha 

az alaprendszer különféle komponenseit be szeretnénk állí- 
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tani (ISDN, Bluetooth, PPP, stb). Fontos azonban tudatában 
lenni annak, hogy a telepített programok nem az alaprend- 
szerrel közös könyvtárakba kerülnek, hanem a /usr/loca[/ 
könyvtár alá, ahol elegendő program telepítése után határo- 
zottan felismerhető lesz egy teljes gyökérkönyvtár. Például 
egy feltelepített Apache webkiszolgáló program beállítása 

a Linux esetén megszokott /etc/apache/httpd.conf helyett 

a /usr/local/etc/apache/httpd.conf állományt használhatjuk. 
Ez eleinte kicsit szétszórtnak tűnik, de hamar megtanulható, 
hogy az alaprendszeren kívüli összes program a /usr/loca[/ 
alatt található meg. Különösen akkor kettős ez az állapot, 
ha az alaprendszer szerves tartozékát külső programként 

is feltelepítjük (GNU C fordító, PERL, SSH, Sendmail). 
Segítséget jelenthet, hogy ez a , filozófia" végigkövethető 

a legtöbb komponens esetén. Például az alaprendszer prog- 
ramjait a /etc/rc.d/ könyvtár alá tett kis programocskák in- 
dítják, a pluszban feltett programokat pedig a /usr/local/ 
etc/rc.d/ alatti programocskák. Például az SSH futásának 
ellenőrzése a /etc/rc.d/sshd status futtatásával leszünk ké- 
pesek, mivel az SSH az alaprendszer része; ellenben az 
ApacheZ2 elindítása a /usr/local/etc/rc.d/apache2.sh start pa- 
ranccsal történhet (mivel ez nem az alaprendszer része). 


A sysetl felület 

A sysctl egy egyszerű program, amellyel a rendszermag 
futás közbeni beállítását ejthetjük meg. Használata teljesen 
azonos a Linux alatt használatos sysct] programmal. Ha 
néhány paramétert minden indítás után be szeretnénk állí- 
tani, akkor ezt a /etc/sysctl.conf állományban tehetjük meg: 


security.bsd.see other uids-0O 


A fájlrendszer 

A FreeBSD fájlrendszere az UEFS (UFS2) nevet viseli, mint 
Unix File System (LINIX fájlrendszer). Némileg eltér a Linux 
alapvető (Ext2) fájlrendszerétől, de alapelveiben azonosak. 
Egy új fogalmat azonban ismerni kell hozzá: ez a Soft 
Updates. Ennek megértéséhez szükséges ismerni a fájl- 
rendszerek néhány tulajdonságát. 

A fájlrendszerek által tárolt adatok alapvetően két részre 
oszthatók: adatokra és metaadatokra. Az adatokkal minden- 
ki találkozott már, hiszen ezekkel dolgozunk. A metaadatok 
ezekről a tárolt adatokról szolgáltatnak információkat a fel- 
használók számára is, de főleg az operációs rendszer felé. 

A számítógépes ,ókorban" minden adatot szinkron írtak 

a tároló eszközökre, vagyis a másolás azonnal megtörtént, 
a programok megvárták a kiírás végét. Ez PC esetén egé- 
így történt. Fel sem merült akkoriban, hogy a drága és ke- 
vés operatív tárat adatok átmeneti tárolására használják fel. 
Idővel azonban a memória olcsóbb lett, ezért kifizetődőbb 
volt az adatok egy részét a sokkal gyorsabb memóriában 
tartani, mint azonnal kiírni a lemezekre. Az adatok akkor 
kerültek ki a lemezre, amikor arra ideje volt az operációs 
rendszernek, illetve amikor ez a gyorsítótár megtelt. 

A metaadatok általában azonnal kiíródtak a lemezre, mivel 
ezzel egyszerűbb lehetett a fájlrendszert kezelő modul. 

A Soft Updates annyit javított ezen a megoldáson, hogy 

a metaadatok is gyorsítótárba kerültek, így sok apró állo- 
mány másolása vagy törlése sokkalta gyorsabb lehetett. 
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Hátrányaként a sérülékenyebb fájlrendszert lehet megemlí- 
teni. Sajnos a FreeBSD naplózós fájlrendszert jelenleg még 
nem támogat rendszerszinten, azonban több éve hallani 
pletykákat ilyen fájlrendszer alkalmazásáról. Reménykedni 
tudunk csak, hogy ez a közeljövőben valósággá válik, addig 
is kerülő megoldásként az 5.x sorozat már képes váratlan 
újraindulás (áramszünet vagy rendszerhiba) után háttérben 
lefuttatni a fájlrendszer ellenőrzését. 


A sysinstall program 

Mint már említettem, ez a program a FreeBSD mindenese, 
amely helyileg a /usr/sbin/ könyvtárban található. Használa- 
tához alapvető angol tudás szükséges, mivel magyarosítása 
egyelőre még tervben sem szerepel. 

A telepítés során kénytelenek voltunk megismerkedni 

a használatával, meglepetés lehet azonban, hogy a feltelepí- 
tett rendszer esetén is azonos menürendszert láthatunk, 
amelyből az első utáni három menüpont a telepítést indíta- 
ná el. Legyünk mindig körültekintőek a használata során, 
bár egy újabb telepítést nehéz akaratlanul véghezvinni, 

de jobb a békesség. 

A telepített rendszer beállításához igazából egyetlen me- 
nüpontot használhatunk a főmenüből, s ez a , Configure" 
nevet viseli. Ebbe belelépve a leggyakoribb alaprendszert 
illető beállításokat meg tudjuk ejteni. 


Uj alaprendszer letöltése 

A FreeBSD egyik jó tulajdonsága, hogy az alaprendszer fo- 
lyamatosan változik, s ezt a változást könnyedén követhet- 
jük a telepített rendszerünk esetén. Ehhez egy kicsit bele kell 
mélyedni a CVS működésébe, amely egy egyszerű elvet való- 
sít meg: sok fejlesztő közös munkáját hangolja össze. Maga 

a CVS használata nem egyszerű tevékenység, viszont remek 
programok készültek e tevékenység egyszerűsítésére. Mivel 
a FreeBSD használói között elenyésző az alaprendszert fej- 
lesztők száma, ezért a készítőknek egyszerű és könnyen 
használható eszközt kellett adni a rendszergazdák kezébe. 
Ez az eszköz cvsup, amely egyetlen feladata, hogy a FreeBSD 
CVS kiszolgálójáról (vagy annak tükörszervereiről) letöltse 

a legújabb alaprendszer és rendszermag forrását. Erre egy 
egyszerű FIP kapcsolat is elég lenne, viszont a teljes forrás 
400-450 megabájt méretet jelent. Ezért aztán a cvsup képes 
arra, hogy kiderítse a különbségeket és csak azzal terhelje 

a hálózatot. Ezáltal alig néhány száz kilobájt forgalmat okoz 
heti rendszerességgel történő ellenőrzéseket alapul véve. 

A legelső probléma az szokott lenni, hogy nincs feltelepítve 
a cvsup program (noha szerintem lehetne az alaprendszer 
része is :), ezért fel kell telepíteni. Ennek egyik módja 

a sysinstal] programot használva a ,Configure", majd 

a ,Packages" menüpontba lépve a telepítési médium kivá- 
lasztása után megkeressük és feltelepítjük a cvsup progra- 
mot. Másik módja, hogy parancssorban kiadjuk a pkg. add 
-r -v cvsup parancsot, amely megpróbálja letölteni és felte- 
lepíteni. Igazából a sysinstal1 is apkg. add programot fog- 
ja meghívni, de mégis egyszerűbbnek látszik a használata. 
A programok telepítéséről azonban a következő részben 
sokkal részletesebben foglalkozok. A következő probléma 

a cvsup helyes és jól működő beállítása. Ehhez egy úgyne- 
vezett sup állományt használunk, amely például így nézhet 
ki (az állomány neve lehet például src-sup): 
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"default 
"default 
"default 
"default 
"default 
"default 


host-cvsup.hu.freebsd.org 
base-/usr 

prefix-/usr 

release-cvs tag-RELENG 5 
delete use-rel-suffix 
compress 


src-all 


Itt megadjuk a használandó kiszolgáló nevét, néhány 
fontos és kevésbé fontos paramétert, illetve a haszná- 
landó ágat. Ez utóbbi több szót érdemel, ennek hibás 
beállításával hamar megszabadulhatunk a teljes /usr/src/ 
tartalomtól is, ugyanis nem létező tag-et használva 

a cvsup egyszerűen letörli az eddig használt forrásokat. 
Természetesen használhatjuk például a RELENG 5. 2 tag-et 
is, melynek hatására megmaradunk az 5.2 verziónál, s 
csak a biztonsági frissítések fognak újdonságot jelente- 
ni. Ez utóbbit akkor érdemes használni, ha olyan prog- 
ramokkal dolgozunk, amelyek egy jól meghatározott 
FreeBSD verzióhoz kötődnek. Javaslom a RELENG 5 
használatát, amely esetén királyi utunk lesz az 5.x ver- 
ziók közötti váltás során, illetve ezzel biztonságosan 
végig tudjuk követni a stabil 5.x ágat, minden stabilnak 
ítélt újdonságról értesülünk a /usr/src/UPDATING állo- 
mányt böngészve. A források letöltését a cvsup src-sup 
parancs kiadásával indíthatjuk el, a program folyama- 
tosan információkkal szolgál az éppen módosított állo- 
mányokról. 

Az alaprendszer nem igényel különösebb beállítást, 
mivel minden ilyen irányú tevékenységet a /etc/ könyv- 
tárban hajthatunk végre, a rendszermag könnyedén a gé- 
pünkre szabható. Ehhez meg kell keresnünk a /usr/src/ 
sys/1386/conf/ könyvtárt, benne pedig a GENERIC állo- 
mányt: ez tartalmazza a kernel beállításait. Szerkezete 
egyszerű, opciókat és eszközöket sorol fel, amelyek 
közül kivehetjük a szükségtelen eszközöket (például 
RAID és SCSI kártyák), illetve hozzávehetünk szükséges 
opciókat (például OUOTA). Célszerű a GENERIC állo- 
mányról egy másolatot készíteni, hogy bármikor vissza- 
térhessünk egy működő beállításhoz. Az új alaprend- 
szer és rendszermag fordításáról illetve telepítéséről 

a következő részben írok. 


Auth Gábor (auth.gaborXDenaplo.hu) 

Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 
kigyógyulni. 





A FreeBSD projekt honlapja 5 http:/Avww.freebsd.org, 


A magyar FreeBSD honlap 3 http:/Avww.freebsd.hu, 
A magyar BSD honlap 5 http:/Avww.bsd.hu, 

A kézikönyv magyar fordítása 

5 http:/Avww.enaplo.hu/FreeBSD/handbook/. 

















A PLplot függvényábrázoló könyvtár 


Elérkezett a C nyelven használható diagram varázslók ideje! Egy merész állítás 


bizonyítása következik. 


gész éjszaka számolt a gép -— de az eredményt 
ke jelentő számsor önmagában nem mond túl sokat. 

Rengeteg munka volt az algoritmus megalkotása, 
viszont a látványra éhes kívülállókat a puszta számadatok 
nem győzik meg. Mit lehet ilyenkor tenni? Az egyik lehet- 
séges megoldás szerint az eredménylistát bemásoljuk egy 
táblázatkezelőbe, majd meghívjuk azt a ,tündért", vagy 
varázslót" (mikor kit), aki másodpercek alatt mutatós 
grafikont állít elő adatainkból. Ha viszont erre a saját prog- 
ramunkból mi magunk is képesek vagyunk, miért választa- 
nánk a kerülőutat? 


Kedves naplóm! 

Valószínűségszámítást hallgatok az egyetemen. Az elő- 
adó szép számmal ad olyan feladatokat, melyek kísérle- 
tek ezerszer, vagy akár több tízezerszer történő elvégzé- 
sén és megfigyelésén alapulnak, és így számítógépes 
szimulációt igényelnek. Az eredményekből viszont csak 
úgy kaphatunk átfogó képet a megfigyelt jelenségekről, 
ha grafikusan is ábrázoljuk az eredményeket. Mivel 

nem voltam hajlandó föladni a C nyelv használatát, 
kénytelen voltam keresni egy olyan könyvtárat, amivel 
kedvenc programnyelvemből is készíthettem látványos 
bemutatót. 

Igen egyszerű módszerrel álltam neki a keresésnek. 
Miután Debian Woody-t használok, elindítottam a dselect 
nevű csomagkezelő segédprogramot, majd leütöttem a / 
gombot és beírtam, hogy plot. Több alkalmazás nevében 
is szerepelt ez a szó, de csak egy olyat volt közöttük, ami- 
hez volt súgó csomag is. Azonnal telepítettem tehát 

a plplot, plplot-dev, és a plplot-doc csomagokat. Első lé- 
pésként a mellékelt példaprogramokat szerettem volna 
lefordítani, de erőfeszítésem kudarcba fulladt. 

A gcc feloldhatatlan hivatkozások (undefined reference) 
tömkelege miatt dobott hibaüzeneteket. Ez természe- 
tes, gondoltam, hiszen nem adtam meg neki, hogy me- 
lyik függvénykönyvtárat kell hozzáfűzni (link) a prog- 
ramhoz. Póriasan fogalmazva nem mutattam meg, hogy 
melyik fájlban vannak a PLplot függvények. Vakon bíz- 
va a leírásban nekiveselkedtem a könyvtárhoz mellékelt 
80 oldalas .,s dokumentumnak, ám ezzel kapcsolatban 
nem találtam semmit. Ekkor döntöttem úgy, hogy elláto- 
gatok a PLplot hivatalos oldalára. 
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A 5 http://wvww.plplot.org/ oldalon ugyanazzal az állomány- 
névvel már egy enyhén szólva kibővített, 160 oldalas leírás 
köszöntött, amit azon nyomban le is töltöttem. A kinyom- 
tatott változat böngészése közben ráakadtam a megoldás- 
ra. A pIplot-config szkript megfelelő módon történő 
meghívásával rövid úton letudhatjuk a fordító paramé- 
terezését. Diadalittasan ütöttem be egyenként a szkript 
nevének betűit, de a gúnyosan villogó kurzor felett csak 
egy rideg elutasítás fogadott a Bash részéről: ,,a parancs 
nem található". 

A megoldás küszöbén nem rettenthet el egy ilyen apróság, 
gondoltam, így letöltöttem a PLplot legfrissebb forrását. 

Az 5.3.1-es változat kitömörítése után a megszokott s 


. /configure 
make 
make install 


lépéseket követve kisvártatva egy működő PLplot változat 
büszke tulajdonosává váltam. Friss függvénykönyvtár, friss 
leírás és egy plplot-config parancsállomány fogadott 

a /usr/local különböző alkönyvtáraiban. A példaprogramok 
már gond nélkül fordultak, így ezzel a fegyverarzenállal 
bátran vághattam neki a programfejlesztésnek. 


Egyfajta varázslat 
Vágjunk bele a sűrűjébe! Az alábbi program egy közönsé- 
ges parabolát (y—x" függvényt) ábrázol. 


finclude cstdio.h: 
finclude cstdlib.h: 
finclude cmath.h: 
finclude cplplot.h: 


int main O 

í 
const PLFLT a — -5., b -— 5., step — .1; 
const PLINT points - ceil ((b - a) / step) 4 1; 
PLFLT "x, "y, t, min[2], max[2]; int i; 


if (NULL -—— (Xx - (PLFLT ") malloc (sizeof 
5 (PLFLT) " points))) ( 
perror ("malloc"); 
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return 1; 
: 
if (NULL —- (y - (PLFLT ") malloc (sizeof 
5 (PLFLT) " points))) ( 
perror ("malloc"); 
return 2; 


[01 - max [1] -— 0; 
b; i 44, t 4— step) ( 


min [0] - min [1] - max 
for (1-0, tsz árt az 





x [li] - t; y [i] - pow Ct, 29; 
if (min [1] 5 y [i]) ( 
mini LO] ex t1l;.műn TT ex til 
g 
if (max [1] c y [i]) ( 
max [0] - x Lil; max [1] — y [il; 
§ 
s 
ffevedededee ete etede de de ete dte de de de dee dtedte ütt ere / 
piszó10 (0.255, 2555 2590 
plscol0 (1, 0, 0, 0); 
plscol0o (15, 255, 0, 0); 
plinit O; 
plenv (a, b, min [1], max [1], 0, 0); 
pllab (Céx", "y", "f(x) - xitulttd"); 
plcol0 (99; 
plline (points, x, y); 
plcol0 (15); 
plpoin (1, gmin [01], gmin [1], 0); 
plcol0 (159; 
plpoin (1, €max [01], €max [1], 0); 
plend O; 
free (y); free (x); 
return 0; 
3 


Mielőtt részletesen elemeznénk a program működését, 
próbáljuk ki! Indítás után azonnal egy kérdéssel szembe- 
sülünk: 


Enter device number or keyword: 


ENTER-t ütve rögtön szemünk elé tárul a gyönyörű grafi- 
kon, kék színnel jelezve magát a görbét. A legkisebb és 

a legnagyobb függvényérték egy-egy piros négyzettel 

van kiemelve. (Mint tudjuk, az x? függvénynek nincs maxi- 
muma, ezért őszintén remélem, hogy a matematika iránt 
olthatatlan szerelmet érző olvasók elnézik nekem ezt 

a fogalmazási pontatlanságot. Később visszatérek rá, hogy 
miért engedtem meg magamnak ezt az eléggé el nem ítél- 
hető hanyagságot.) 

Térjünk vissza a program által feltett kérdésre. Ez arra vo- 
natkozik, hogy a PLplot különböző függvényein keresztül 
előállított ábra milyen eszköz segítségével kerüljön megjele- 
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nítésre. Az első lehetőség — amely egyben az alapértelme- 


zett is — a grafikus felületen, vagyis egy X ablakban való 
megjelenítés. Ezen kívül a PLplot a legkülönfélébb eszkö- 
zökhöz rendelkezik meghajtóval. Attól függően, hogy mit 
adtunk meg a fordítás során választhatunk Postscript, Xfig 
és JPEG kimenet között. 

Maga a program a beillesztendő fejlécállományok sorával 
kezdődik. A stdlib.h a dinamikus memóriakezelés, 

a math.h a hatványozást biztosító powO függvény, míg 

a plplot.h a cikk tárgyát képező függvénykönyvtár defi- 
nícióihoz szükséges. A plplot.h tartalmazza ezen kívül 

a PLFLT lebegőpontos, illetve a PLINT egész típusokat is, 
melyek a könyvtár használata esetén igen hatékonyan 
alkalmazhatók a számábrázoláshoz. 

A program belépési pontja, amely jelen esetben az 
egyetlen függvény, a mainO. Az első három sorban ve- 
zetjük be az új változókat. A PLplot segítségével X-Y diag- 
ramokat tudunk megjeleníteni. Az ábrázolás az a és b ál- 
tal meghatározott zárt intervallumban fog történni, az 
ábrázolási lépésközt pedig step jelzi. A points nevű 











változóban tároljuk a ténylegesen kiszámítandó, és megje- 
lenítendő pontok számát. Az összes többi pont számítása 
interpolációval történik. 

Az X-Y diagram pontjai egy x és egy y nevű tömb elemei 
lesznek, természetesen úgy, hogy a két tömb azonos indexű 
tagjai alkotják egy pont koordinátáit. Bevezetünk egy t se- 
gédváltozót, egy-egy két elemű tömböt a minimum, és 

a maximum ábrázolásához, valamint egy i ciklusváltozót. 
Ez után két mal locO) hívás következik, melyekkel területet 
foglalunk az x és az y tömbnek. Természetesen meg lehetett 
volna ezt oldani statikus tömbökkel is, ám ez rontana 

a program rugalmasságán. 

A min, illetve max tömbök minden elemének 0 kezdőérté- 
ket adunk. Az ezt követő ciklusban számoljuk ki a görbe 
egyes diszkrét pontjait, illetve meghatározzuk a függvény 
minimumát és maximumát. Az i változót csupán az x, 

és y tömbök indexeléséhez használjuk, míg a t futó változó 
az intervallum pontjait veszi fel a megadott léptéknek 
megfelelően. A ciklus lényegét jelentő első sor a ciklus- 
magban magáért beszél. Az utána álló két elágazás egy 
megszokott módszer legalacsonyabb, illetve legmagasabb 
érték keresésére. 

A megjegyzés után álló rész használja ki a PLplot függ- 
vénykönyvtár adta lehetőségeket. A PLplot biztosítja 

a programozót arról, hogy bármilyen eszközt is használ 

a megjelenítéshez, egy 16 színű paletta mindig rendelkezé- 
sére áll. Ennek a 0. színe jelenti az alapértelmezett hátteret, 
és az 1. az előteret. Ha ezeket nem módosítjuk, fekete háttér 
előtt piros színnel rajzol a könyvtár, ami a képernyőn még 
tűrhető, de nyomtatásra nem használható. Éppen ezért az 
első három sorban módosítjuk a palettát. 

Nulladik színnek fehéret, elsőnek pedig feketét állítunk 
be (RGB megadás). Azért, hogy a piros továbbra is elérhe- 
tő maradjon, beírjuk a 15. szín helyére. A plinitO függ- 
vényt minden ábrázolás előtt meg kell hívni, mivel bizo- 
nyos belső változóknak ez ad kezdőértéket. Lehetőségün 
van arra, hogy a plinitO meghívása előtt a programból 
meghatározzuk a kimeneti eszközt a pIsdevO függvény 
segítségével. Ha ez elmarad, akkor a plinitO felkínál 
egy listát a felhasználónak az elérhető eszközökről, és az 
ő döntésén múlik, hogy az eredmény milyen formátum- 
ban jelenik meg. 

A plenvO az ábrázolás környezetét állítja be. Első két para- 
métere az x, második kettő az y tengelyen vett alsó és felső 
korlát. Az x tengely beállításához mi az a és b pontokat 
vettük, az y-hoz pedig a számított minimum és maximum 
értékét. Többek között e paraméter miatt használtam az 
imént olyan pongyola módon a minimum és maximum 
fogalmát. A függvény ötödik paramétere adja meg, hogy 

a két tengely skálája azonos legyen-e (1), vagy sem (0). 

Az utolsó paraméter a különböző címkék, tengelyek, rá- 
csok megjelenítését állítja be. Mi itt csak egy dobozt kérünk 
a diagram köré, de az egyéb lehetőségekről bőven találunk 
leírást a dokumentációban. 

A pllabO függvény segítségével határozhatunk meg cím- 
kéket az x és y tengelyhez, illetve itt adhatjuk meg a diag- 
ram címét. A karakterláncokat, amelyek különféle módosí- 
tókat is tartalmazhatnak, a jelzett sorrendben kell átadni,. 
Egy módosító mindig t karakterrel kezdődik, és hasonló 
beállításokra használható, mint a legtöbb szövegszerkesztő 
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Formátum/ Karakter... menüpontja. A ítu az angol up (fel) 
jele, míg a ítd a down (le). A bemutatott módszerrel a 2-es 

a felső indexbe kerül. Ha netán magára a t karakterre len- 
ne szükségünk, azt a tti jelsorozattal jeleníthetnénk meg. 
Ha valamelyik címkét nem szeretnénk megadni, ott az üres 
karakterláncot kell átadni és nem NULL-t! 

Ezután jön a görbe megrajzolása. Előbb az előtérszínt állít- 
juk be kékre a plco100 függvény segítségével. Az alapér- 
telmezett palettában a kék a 9-es szín. Utána a pllineO 
függvényt használjuk, mely két tömb megadott számú ele- 
me alapján hoz létre egy képet. Első paraméterként átadjuk 
a pontok számát, második és harmadik paraméterként az x 
és y tömböket. Utóbbiak azonos indexű elemei alkotják egy 
pont koordinátáit. A függvény a szomszédos pontokat egy 
vonaldarabbal összeköti. 

A maximum és minimum bejelölése is hasonlóan történik. 
Először beállítjuk pirosra az előtérszínt. Vegyük észre, hogy 
azért kapunk pirosat a 15-ös kiválasztásával, mert amikor az 
elején átrendeztük a palettát, ezt állítottuk be. A plpoinO 
hasonlít a pllineO) -hoz, de nem húzza össze a szomszédos 
pontokat és lehetőség van a pontok karakterének megvá- 
lasztására. Első paramétere az ábrázolandó pontok száma, 
második és harmadik az x és y tömbök. Mivel egyetlen 
pontot ábrázolunk, kénytelenek voltunk a változó címét ké- 
pezni, hogy hasonlítson egy tömbre. Az utolsó paraméterrel 
a 0-ás karaktert választjuk ki, ami épp egy négyzet. 
Legvégül meghívjuk a plendO függvényt. Ez addig nem 
tér vissza, amíg a rajznak nincs vége. Ez egy Postscript do- 
kumentum esetén a nyomtatás végét, egy ablak esetén az 
ablak bezárását jelenti. A plend O visszatérésével a rajz 
megszűnik és a belső változók felszabadulnak. Mivel dina- 
mikusan foglaltunk helyet az x és y tömböknek, ezeket is 
felszabadítjuk egy-egy freeO) hívással a program végén. 

A return 0; utasítással az alkalmazás véget ér. 


0 Kiskapu Kft. Minden jog fenntartva 


Hogyan tovább? 

A fenti példaprogram amolyan állatorvosi ló, amin min- 
dent ki lehet próbálni. Megpróbálkozhatunk például 

a sin(x) függvény ábrázolásával. Ehhez nem kell mást 
tennünk, mint a for C; ; ) ciklus magjában megfelelően 
módosítani azt sort, amely értéket ad az y[Li] tömbele- 
meknek. 

A PLplot természetesen sokkal többet tud annál, mint amit 
ebben a cikkben megmutattam. Nem csak C-hez, de Ct--- 
hoz, Fortranhoz, Perlhez, TcI/Tk-hoz, és Java-hoz is van felü- 
lete, így szinte bárhol használható. Sőt, működik Microsoft 
Windows alatt is! A Visual Studio-val könnyedén le lehet 
fordítani könyvtárat, akár DLL-t is lehet belőle készíteni. 
Ez egyben azt is jelenti, hogy a PLplot-tal készül progra- 
mok forráskód szinten hordozhatóak. A könyvtár fejleszté- 
se nem állt meg, folyamatosak a frissítések. 

A PLplot lehetőséget biztosít oszlop-, torta-, és 3 dimenziós 
diagram létrehozására, vannak benne különböző vonal- 

és kitöltési stílusok, valamint különleges betűkészletek is. 
Akit érdekel a grafikus ábrázolás, mindenképpen töltse 

le a leírást, és szánjon rá egy-két délutánt az átolvasására. 
Megéri foglalkozni vele, mert egy idő után gyerekjáték 

a használata. Sok sikert hozzá! 


Fülöp Balázs 
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. . avagy hogyan használjuk okosan az osztályokat, és objektumokat PHP 5-ben. 


nnak idején, amikor a PHP 3-at leváltotta 
A a PHP 4, egy hasonló átállásnak lehettünk 

tanúi, mint most. A programnyelv fejlesztői 
nagyon odafigyeltek arra, hogy az új rendszerrel kom- 
patibilis maradjon a kód, vagyis igyekeztek minimális- 
ra csökkenteni azoknak a programoknak a számát, 
amelyek nem futnak az új PHP-vel. Tudjuk, hogy az átál- 
lás nem mindig volt sikeres, de legalább megpróbálták... 
És valljuk be, azért nem olyan rossz az eredmény, amit 
elértek. Az új változat tartalmazott néhány új megoldást, 
pár koncepcionális újítást, filozófiai jellegű helyretételt, 
amelyek hosszú távon igen jelentősek a programnyelv tel- 
jességére, összefogottságára nézve. A nagy változás azon- 
ban az volt, hogy megjelent a ZEND engine 1, ami valójá- 
ban az a virtuális gép, amely a PHP kódot futtatja. Ezzel 
vált igazából platform függetlenné a PHP. 
Hasonló változásokról beszélhetünk mostanság is, a PHP 5 
megjelenésénél. Ami a programozást illeti, itt is olyan jelle- 
gű módosítások történtek, mint annak idején a PHP 4-ben. 
Két fő változat közben a függvény könyvtárak alakulása, 
bővülése természetesen folyamatos, ezzel nem is szükséges 
foglalkoznunk. Ebből a szempontból a PHP 4 vége és 
a PHP 5 eleje gyakorlatilag ugyanazt tudja, ám a PHP 5 
bevezetéséhez időzítettek jó néhány teljesen új függvényt, 
csakhogy könnyebb legyen az életünk. Ami igazán új, az 
a már említett virtuális gép a ZEND, amely már a 2-es válto- 
zatszámot viseli. Ellátták néhány új képességgel, átalakult 
a memóriakezelés, gyorsabb lett, stabilabb lett, azonban mi 
programozók, ebből nem sokat látunk. 
Ami viszont rendkívüli módon — mondhatni teljesen — át- 
alakult, az az objektummodell. Ezzel a PHP talán leggyen- 
gébb bástyáját sikerült igencsak megerősíteni: olyan mér- 
tékben kibővült, hogy akár komoly dolgokra is használni 
lehet. A régi modell csak erős jóindulattal teljesítette azokat 
az alapkritériumokat, amelyek egy objektumközpontú 
nyelvnek sajátjai. Nem volt igazi egységbe zárás, s a több- 
alakúság is csak úgy teljesült, ha programozóként betar- 
tottuk az ehhez szükséges szabályokat -— szerencsére ez 
nincs többé. 
Nem véletlen tehát, hogy a most induló cikksorozatunk 
is szinte kizárólag erről fog szólni. Egyrészt azért, hogy 
mindenki megismerje az új szolgáltatásokat, másrészt, 
hogy a tisztelt olvasó kedvet kapjon az objektumok okos, 
átgondolt használatához, amivel jelentősen megkönnyítheti 
saját dolgát - ha programozni támad kedve. Éppen ezért 
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— a sorozat alcímének megfelelően - az alapoktól kezdve, 

a szintaktika mellett a szemlélet áttekintésével próbálom 
elővezetni mondandómat. Remélem az Olvasó is méltónak 
találja majd írásomat az ott említett jelzőre. 


Osztályok és objektumok 

Mint tudjuk, az osztályok olyan kerek, egész szerkezetek, 
amelyekben nem csak értékeket tárolhatunk, de azok segít- 
ségével különböző műveleteket végezhetünk, utasításokat 
hajthatunk végre. Olyan összetett típusok tehát, amelyek- 
ben nem csak adat, hanem logika is található. 

A legfontosabb változás a PHP 4-hez képest, amelyet 
mindjárt az elején meg kell említsek, hogy az osztályok 
példányaira, az objektumokra ezentúl referenciaként hi- 
vatkozunk. Előzőleg, ha egy objektumot átadtunk bárho- 
gyan a programban, az lemásolódott, és egy új példány 
jött létre, azon végeztük azután a műveleteket. PHP 5- 
ben, ha átadunk egy objektumot, például valamilyen 
függvénynek, akkor annak az hivatkozásként, referenci- 
aként adódik át, ami a gyakorlatban azt jelenti, hogy az 
objektum csak egyszer szerepel a memóriában, és amikor 
valahonnan használjuk, valójában arra a memóriaterü- 
letre hivatkozunk, ahol az elhelyezkedik. Ha tehát átmá- 
soljuk az objektumunkat egy másik , változóba", az iga- 
zából ugyanaz a változó marad, amit ezután két módon 
is elérhetünk. 


Uj osztály létrehozása 

Új osztályt még mindig a megszokott módon kell létrehoz- 
ni, azaz a class kulcsszóval, amit az osztály neve követ, 
majd kapcsos zárójelek között az osztály definíciója. 
Lássunk erre egy példát: 


c?php 

class Negyzet í( 
private $oldal — 0; 
private $terulet — 0; 


public function oldalHossztBeallit($ertek) ( 
$this-soldal1-$ertek; 
$this-sterulet-$erte"$ertek; 

J 


public function terulete) ( 
echo $this-sterulet; 











3 

$negyzet - new NegyzetO ; 
$negyzet-soldalHosszBeallit(7) ; 
$negyzet-steruleteO ; 

7? 


Ez majdnem olyan, mintha PHP 4-ben íródott volna. 

Az osztály a new kulcsszó segítségével példányosítható. 

A $this különleges változó arra szolgál, hogy az osztályon 
belül a saját tulajdonságokra, tagfüggvényekre hivatkoz- 
hassunk. Az osztály egy példánya egy konkrét elemre (ese- 
tünkben a négyzetek közül egy konkrét négyzetre) vonat- 
kozik, ebben eddig nincs is semmi különleges. 

Ha azonban jobban megnézzük a kódot, ott van az a bizo- 
nyos public, illetve private kulcsszó. Mi is ez valójában? 


Nyilvánosság — az egységbe zárás kulcsa 

A PHP 5-ben is bevezették a más objektumközpontú nyel- 
vekben már régen használatban lévő adattulajdonságokat, 
amelyek arra hivatottak, hogy segítségükkel elrejtsük az 
osztályban szereplő tagfüggvényeket, osztályváltozókat. 
Erre azért van szükség, hogy az osztály által nyújtott szol- 
gáltatásokhoz, erőforrásokhoz csak az osztályban megvaló- 
sított, szabványos felületeken keresztül férhessünk hozzá, 
s ne tehessünk kerülőutakat, melyek használata rövid időn 
belül átláthatatlanná teszi kódunkat. A fenti példa alapján 
képzeljük el, hogy a négyzet oldalát nem az erre írt tag- 
függvényen keresztül állítjuk be, hanem közvetlenül, az 
$oldal osztályváltozón keresztül. Ekkor a négyzet területe 
természetesen nem számítódik ki, nekünk kell azt megten- 
ni, s ha netán elfelejtenénk, az osztályunk már is helytelen 
működést produkál. A megoldás az, ha megtiltjuk, hogy 
az $oldal változóhoz közvetlenül is hozzá lehessen férni 
(ezt jelzi a private kulcsszó). 

Ennek megoldására a klasszikus séma szerint három tulaj- 
donság áll rendelkezésünkre, amelyet az osztályváltozókra 
és tagfüggvényekre egyaránt alkalmazhatunk. 


e public: Ez az alapértelmezett tulajdonság. Ha nem 
adunk meg semmit, akkor automatikusan nyilvános lesz 
az osztályelem. A nyilvános elemek elérhetők az osztály 
példányán keresztül a -: operátor segítségével — min- 
den korlátozás nélkül. Azokat a tagfüggvényeket tehát, 
amelyeket kifejezetten arra célra készítünk, hogy 
a program egyéb részeiből használjuk, nyilvánosnak 
kell deklarálni. 


e private: Az ilyen módosítóval ellátott elemek csak az 
adott osztály belsejében lévő programkódból érhetők el. 


e protected: A védett tulajdonságot majd csak később 
fogjuk jól megérteni. Az így jelölt elemek csak azokból 
az osztályokból érhetők el, amelyek az adott osztályból 
öröklődnek (és természetesen önmagából is). Ez valójá- 
ban arra szolgál, hogy azért ne zárjuk ki teljesen az 
adott változót a további műveletből. Ha egy osztályt 
továbbfejlesztünk az öröklés módszerét választva, igen 
nagy korlátokba ütközhetnénk, ha nem érhetnénk el 
az ősosztály meghatározott változóit. 
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Ezeket az adattulajdonságokat helyesen alkalmazva elér- 
hetjük, hogy az általunk írt osztályokat csak olyan módon 
lehessen használni, ahogyan azt mi megálmodtuk. A ponto- 
san meghatározott használhatóság pedig lehetővé teszi szá- 
munkra, hogy építsünk rá. 


Konstruktorok és destruktorok 

Ha megnézzük, a fenti példában az osztály használatát, 
láthatjuk, hogy a példányosítás során jó volna, ha nem 
kellene külön beállítanunk a négyzet oldalát, feltételezhe- 
tő, hogy ha egy négyzetet akarunk , csinálni", annak van 
valamilyen hosszú oldala. Ilyen helyzetek megoldására ta- 
lálták ki a konstruktorokat. Ezek valójában különleges tag- 
függvények. Automatikusan meghívódnak, amikor a new 
kulcsszó segítségével létrehozunk egy példányt, ezáltal 
bizonyos kezdeti értékek beállítására kiválóan alkalma- 
sak. PHP 4-ben azok a metódusokat tekintette a nyelv 
konstruktoroknak, amelyek azonosak voltak az osztály ne- 
vével. Ez mostanra megváltozott. A konstruktorokat min- 
den körülmények között . consturct névvel kell illetni. 
Lássunk erre egy példát, egészítsük ki a fenti osztályt az 
alábbi tagfüggvénnyel: 


public function . construct($oldal) ( 
$this-soldalHosszBeallit($oldal1) ; 
3 


Most pedig példányosítsuk az osztályt úgy, hogy egyből át 
is adjuk az oldal hosszát: 

$negyzet - new Negyzet(7); 

Hasonló módon kell értelmezni a destruktorokat is, ame- 
lyek akkor hívódnak meg, amikor az osztály egy példánya 
megszűnik létezni. Általában arra szokták őket használni, 
hogy az osztály által használt erőforrásokat (adatbázis- 
kapcsolat, fájlleíró) felszabadítsák. Destruktorok nem voltak 


a PHP 4-ben, csak most kerültek bevezetésre. Egészítsük ki 
a példaosztályunkat egy destruktor tagfüggvénnyel: 


public function . destructO ( 
echo "A négyzet oldalhossza elhalálozásának 
5 időpontjában: $this-soldal" 


J 


Ha lefuttatjuk a programunkat, akkor a program végeztével 
a PHP automatikusan felszabadítja a változókat, tehát min- 
den példányra meg fog hívódni a destruktor, amely kilistáz- 
za nekünk, hogy mekkora volt a négyzet a futás végén. 
(Ugyanez az eredmény történik, ha kézzel, az unsetO 
függvénnyel szabadítjuk fel az objektumunkat.) 


Statikus változók, tagfüggvények 

A statikus elemek olyan résztvevői az osztályoknak, ame- 
lyek nem élnek együtt azok példányaival, sokkal inkább kö- 
tődnek az osztályhoz, magához. Statikus elemek eléréséhez 
nincs is szükségünk az objektumokra, az osztályra hivat- 
kozva érhetjük el azokat. A statikus elemeket a static 
kulcsszóval vezethetjük be, amelynek minden esetben az 
adattulajdonságokat jelölő kulcsszó után kell következnie. 
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Hogy mindezt megértsük, egészítsük ki a fenti osztályunkat 
az alábbi tagfüggvénnyel: 


public static leirasO ( 
echo ,Én egy olyan osztály vagyok, aki 
s négyzeteket képvisel"; 


Hi 


A fenti függvénynek ugyan sok értelme nincs, de jól szem- 
lélteti a lényeget. A statikus elemekre a Scope C: : ) operá- 
torral hivatkozhatunk. Lássuk: 


Negyzet: : leirasO; 


Mint látható, anélkül, hogy példányosítottuk volna az 
osztályt, leírást kérhetünk róla. Jól látható az is, hogy az ilyen 
tagfüggvények nem kötődnek szorosan az osztályhoz, nem 
használják ki azt, hogy az osztályok adatokat és logikát tartal- 
maznak. Egy statikus metódus csupán , logika", nem köthető 
az osztály adataihoz. Ezek után szinte természetes, hogy nem 
is hivatkozhatunk benne hagyományos osztályváltozókra, 
tehát sehol nem fordulhat elő benne a $this kulcsszó. 

Ha már a hivatkozásoknál tartunk: megszokhattuk, hogy 

a $this változón keresztül érhetjük el többek között az osz- 
tály saját tagfüggvényeit. Ez statikus esetben nem működik, 
mivel ott nem is beszélhetünk példányról, ezért itt a self 
kulcsszó használata a megoldás. Ha például a konstruktor- 
ban ki szeretnénk írni, hogy mely osztályról is van szó, 
akkor beletehetjük a 


self::leirasO; 


sort, amely meghozza a kívánt eredményt. 

Az osztályváltozók esetén is ugyanaz a helyzet, mint a tag- 
függvényeknél. Ők is lehetnek statikusak, ekkor hasonló 
tulajdonságok érvényesek rájuk is. Logikailag azonban né- 
miképp bonyolítható a helyzet. Ha statikus változókat hasz- 
nálunk, akkor nem nehéz kitalálni, hogy ezek a változók az 
osztály minden példányából ugyanúgy, egyediként látsza- 
nak. Ha tehát az egyik példány megváltoztatja egy statikus 
változó értékét, azt utána minden példány , érzékelni" fog- 
ja. Példaként valósítsunk meg a négyzeteket képviselő osz- 
tályunkban példányszámlálást, amelynek segítségével meg- 
mondható, hogy adott pillanatban hány négyzetpéldány 
van jelen a programban. Ehhez az alábbi módon alakítsuk 
át az osztályunkat: 


ca?php 
class Negyzet ( 
private $oldal -— 0; 
private $terulet - 0; 
private static $peldanyszam - 0; 
public function . construct($oldal) ( 


self: : $peldanyszamt-t; 
$this-soldalHossztBeallit($olda1); 


public static function aPeldanyokSzama() ( 
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echo self::$peldanyszam; 


public function oldalHossztBeallit($ertek) ( 
$this-soldal-$ertek; 
$this-sterulet-$ertek"$ertek; 


public function terulete) ( 
echo $this-sterulet; 


public function . destructO ( 
self: : $peldanyszam-—; 


§ 

§ 

$negyzeti - new Negyzet(7); 

$negyzet2 - new Negyzet(2); 

$negyzet3 - new Negyzet(9); 

unset($negyzet1) ; //elpusztitom a negyzeti 

5 peldanyt 
Negyzet : : apeldanyokSszamaO ; 
7: 


A kód futáskor kiírja, hogy két darab példány van jelen épp 
az adott Négyzet osztályból. Ha ugyanis létrejön egy új, 
meghívódik a konstruktor, ami átállítja a számlálót, ami 
mint tudjuk, minden , példányt" érint. (Azért helytelen ki- 
csit a kifejezés, mert a statikus változók a statikus tagfügg- 
vényekhez hasonlóan igazából nem kötődnek az osztály 
példányaihoz - csak annyiban, hogy ha nem statikus tag- 
függvényben hivatkozunk rájuk, akkor minden példány 
ugyanazt" az értéket látja.) 

A példában statikus tagfüggvénnyel fértünk hozzá a hason- 
ló tulajdonságú változóhoz, mert egy , globális", példány- 
független szolgáltatásra volt szükségünk, de ez nem felté- 
tel. Nem statikus metódusokból is módosíthatjuk, lekérhet- 
jük ezeket a változókat, sőt, ekkor válik érdekessé a dolog. 
(Valójában ez történt akkor is, amikor a konstruktorból, 
destruktorból növeltük ill. csökkentettük az osztálytulaj- 
donság értékét, de ez nem mindig tudatosul a példa tanul- 
mányozásakor, ezért hívtam fel rá a figyelmet.) 

Nagyon fontos, hogy megértsük a statikus változók és tag- 
függvények szerepét, jelentőségét, mert ezzel egy halomnyi 
sbűvésztrükköt" tudunk később megvalósítani — olyanokat, 
amelyektől tényleg , szép" lesz az, amit csinálunk. 


Allandók 

A PHP 5 lehetővé teszi állandók (konstansok) bevezetését 
osztályváltozók gyanánt. Ezek nagyon közeli rokonságban 
állnak a fentebb emlegetett statikus változókkal. Egyik fon- 
tos különbség, hogy értékük nem változtatható meg, az 
egyedüli értékadás a deklaráció során történik. A bevezetés 
a const kulcsszóval történik, s fontos megjegyezni, hogy 
nem használjuk a $ változóelőtagot sem a deklarációnál, 
sem később az érték kiolvasásánál! 

A változó értékét szintén a self előtaggal és a scope operá- 
tor használatával kaphatjuk meg, s hasonlóan a statikus 
testvéreikhez, ezek sem érhetők el az objektumpéldányok- 
ból, csakis az osztályon keresztül. 











ca?php 
class Probaosztaly ( 
public const allando - "barmi? ; 
public function konstansErteke() ( 
echo self::allando; 


; 


echo Probaosztaly::allando; //ily módon is 
sselérhetjük 
$osztaly - new ProbaosztalyO; 
$osztaly-skonstansErtekeO ; //ily módon is 
ss elérhetjük 
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Osztályok összehasonlítása 

Az esetek jelentős részében szükségünk lehet arra, hogy 
megmondjuk két objektumról, hogy azok egyenlőek-e. 

A helyzet némiképp bonyolódott a PHP 4-hez képest, 
ugyanis ott csak a azonosság (-——-) operátort használtuk két 
objektum összehasonlítására. Két objektum mindig két kü- 
lön memóriaterületet, azaz két külön , változót" jelentett. 
PHP 5-ben azonban bevezették, hogy az objektumokra 
referenciaként hivatkozunk. Ez máris szükségessé tette az 
összehasonlítás átalakítását: egyenlőséget és azonosságot 
egyaránt vizsgálhatunk 

Az objektumok egyenlőségét az , összehasonlító" (-——) operá- 
torral ellenőrizhetjük. Ekkor a két objektum megegyezik, ha 
ugyanazon tulajdonságai ugyanazokat az értékeket tartal- 


mazták, és ugyanannak az osztálynak voltak példányai 

(Ez a PHP 4-es megegyezőség feltétele is). Mivel azonban 
itt referenciákkal dolgozunk, szükségünk lehet szigorúbb 
ellenőrzésre is, ha azt akarjuk tudni, hogy két hivatkozás 
ugyanarra az objektumra mutat-e. Ehhez használjuk a már 
említett azonosság operátort. Két objektum akkor azonos, 
ha az adott osztály ugyanazon példányaira hivatkoznak 
mindketten. Alapesetben, ha egy objektumot átmásolok egy 
másikba, a két objektum , azonos" lesz. Ez jelentősen bonyo- 
lítja az esetleges valódi" másolást, de a későbbiek folyamán 
megtanulhatjuk, hogy hogyan legyünk úrrá a problémán. 
A fentiek alkalmazásával egy sor fejlett osztályt készíthe- 
tünk az egyszerűbb problémák intelligens elhárítására. Fon- 
tos, hogy feleslegesen ne alkalmazzunk objektumokat, mert 
azzal csak elbonyolítjuk az egyszerű feladatot. Gondosan 
válasszuk meg, hogy mikor és milyen osztályokat készítünk. 
Nos, a cikknek ugyan végére értünk, de a mondanivalónk- 
nak messze nem. Hátra van még például az öröklődés 

— mint nagy témakör, az elvont osztályok, felületek létreho- 
zása, a különleges tagfüggvények használata. Ezekkel és 
más egyéb érdekességékkel foglalkozunk cikksorozatunk 
következő epizódjában. 


Komáromi Zoltán 
(komi(okiskapu.hu) 

23 éves, a BME hallgatója, mellette 
PHP-programozóként dolgozik. 

] Kedvenc területe a multimédia. 
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Értékeld a Linuxvilág 
cikkeit! 


NY lehetőség van rá, hogy pontszámmal értékeld a Linuxvilágban megjelent cikkeket. Minden 
szám tartalomjegyzékében az adott cikk dobozában megjelölheted, hogy milyen osztályzatot adsz rá 


1-től 5-ig. Emellett a cikkek összesítő oldalán is lehetőség van a cikkek értékelésére. 

Egyszerre több cikket is értékelhetsz: jelöld meg, hogy milyen osztályzatot adsz a cikkeknek és kattints 
az oldal tetején vagy alján található , Pontozás" gombra. 

Ha bővebben kívánod véleményezni a cikket, kérjük írd meg a hozzászólásokban. 

Reméljük sokan fognak élni a lehetőséggel és ezáltal hasznos visszajelzést kapunk arról, hogy mely 
cikkek/témák a legnépszerűbbek. Az osztályzatok alapján hamarosan megjelentetünk egy folyamatosan 
frissülő toplistát is. 
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Hálózatok (12. rész) 
Hidak 


Mit tegyünk, ha több LAN-t szeretnénk egymással összekapcsolni? 
Ilyenkor hidakra van szükségünk, amelyekkel akár különböző szabványú 
hálózatokat is együttműködésre bírhatunk. 


inél több állomás van egy LAN-on, az állomások 
Hú] annál nehezebben tudják megszerezni az osztott 

csatornát. Előbb-utóbb már annyira túlterhelt 
lesz az átviteli közeg, hogy a hálózat használhatatlanná vá- 
lik az egyre gyakrabban kialakuló versenyhelyzetek, illetve 
ütközések miatt. A sávszélesség növelése persze jelenthet 
megoldást, de ez gyakran az összes hálózati eszköz lecseré- 
lésével jár, amely sosem olcsó mulatság. 
Van azonban más lehetőség is. Az előző részben bemu- 
tattuk a kapcsolót (switch), amely külsőségeiben némileg 
hasonlít a hubokhoz, de a belső ennél sokkal többet rejt. 
A végpontokra (portok) itt is állomásokat kapcsolhatunk, 
de a tőlük érkező kereteket a kapcsoló — a hubokkal ellen- 
tétben — csak a címzett(ek)nek továbbítja. A kapcsoló te- 
hát egy ,intelligens" eszköz, képes belelátni a rajta átme- 
nő adatokba. Mivel a keretek nem jutnak el oda, ahol 
senki sem kíváncsi rájuk (kivéve persze a hálózaton hallga- 
tózókat, de ők most nem számítanak), csökken a csatorna 
terheltsége. 
Egy kapcsoló végpontjaira ugyanakkor nem csak egyetlen 
munkaállomást köthetünk, hanem akár egy egész , LAN- 
nyit" is. Ettől kezdve a kapcsoló többé már nem kapcsoló, 
hanem híd (bridge). Itt aztán egészen új problémák me- 
rülnek fel, de még mielőtt ezekkel szembesülnénk, vála- 
szoljunk meg egy kínzó kérdést: pontosan miért is van 
szükség hidakra? A kérdést egyből át is fogalmazzuk: 
miért lehet arra szükség, hogy egy szervezeten belül az 
állomásokat több különálló LAN-ba foglaljuk, majd azo- 
kat hidakkal összekapcsoljuk, ahelyett, hogy összerak- 
nánk egy jó nagy hálózatot, amelyhez minden állomás 
közvetlenül kapcsolódna? 
Az első ok már sejthető: a terhelés megosztása. Ahogy 
azt az imént már kifejtettem ha sok az állomás, akkor a 
csatorna terhelt lesz. Ha nem szeretnénk terhelt csatornát, 
akkor meg kell növelnünk a sávszélességet. Nagy számú 
állomás esetében azonban óriási sávszélességre lenne szük- 
ségünk, amelyre nem biztos, hogy szert tudnánk tenni. 
Ilyenkor a hálózatot több részre (szegmensre) kell osztani, 
és valamiképp biztosítani azt, hogy a forgalom nagy része 
ne kerüljön ki a gerinchálózatra (a szegmenseket összekötő 
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közegre), hanem maradjon a különálló részeken belül. 
Miként lehet ezt megoldani? Tegyük fel, hogy van kismillió 
munkaállomásunk. A felhasználók az állományaikat a háló- 
zat fájlszerverén tárolják. Mivel mindenki gyakran végez 
fájlműveleteket, ezért biztos, hogy a LAN a terhelés miatt 
használhatatlanná válik. Kivéve akkor, ha a munkaállomá- 
sokat szegmensekbe szervezzük, és minden szegmenshez 
tartozik egy saját fájlkiszolgáló. Mivel a szegmensekben 
viszonylag kevés állomás van, a csatorna ezeken belül már 
nem lesz különösebben terhelt. 

Hogy miként is képzelhetjük el a szegmenseket, azt az 

1. ábra illusztrálja. A szegmensek különálló LAN-ok, ame- 
lyek valamennyien saját csatornával rendelkeznek. Magu- 
kat a szegmenseket hidakkal köthetjük össze. Ha kevés 
szegmensünk van, akkor elegendő egyetlen kapcsoló, egy 
kiterjedt hálózat esetében azonban elképzelhető, hogy több 
kapcsolót kell egymással összekötnünk. 

Hidakra akkor is szükségünk lehet, ha a hálózat amúgy 
bőven elbírná a terhelést. Előfordulhat például, hogy túl 
messze vannak egymástól az állomások. Bizonyos típusú 
LAN-ok esetében fizikailag korlátozva van a hálózat meg- 
engedett mérete. Az Ethernet esetében ez például 2500 
méter. Vagy nézzük azt az esetet, amikor két különálló 
épületben elhelyezkedő állomásokat szeretnénk egy háló- 
zatba kötni. Sokkal megbízhatóbb, na és persze olcsóbb 
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2. ábra 


megoldás az, amikor a két épületben két különálló LAN-t 
készítünk, és azokat egymással hidak és infravörös átvitel 
segítségével kapcsoljuk össze, mint ha átvezetünk egy 
koaxiális kábelt. 

A hidak másik fontos feladata a különböző szabványú háló- 
zatok közötti átjárhatóság megteremtése (2. ábra). Ilyen 
igény általában akkor szokott felmerülni, amikor már van 
két működő, ám teljesen eltérő típusú hálózat, és utólag ju- 
tott csak az üzemeltetők eszébe, hogy milyen jó is lenne, ha 
a két hálózat egymással is tudna kommunikálni. Van azon- 
ban olyan eset is, amikor direkt különböző szabványú háló- 
zatokat szeretnének telepíteni egy szervezeten belül, mert 
bizonyos feladatokra az egyik alkalmasabb, mint a másik. 
Bármi is legyen a kiinduló ok, ezt a feladatot a hidaknak 
meg kell oldaniuk. Sejthető, hogy ez nem könnyű, hiszen 
például a vezérjeles gyűrű (token ring) más keretmérettel 
dolgozik, mint az Ethernet, de sok más egyéb alapvető kü- 
lönbség is van. 

Még egy dolog van, ami miatt áldott a hidak tevékenysé- 
ge, ez pedig a megbízhatóság és a biztonság szempontjá- 
ból érdekes. Az utóbbiról már volt szó az előző részben. 
Mivel az adatszórós hálózaton mindenki hallhat minden- 
kit, ezért könnyen lehallgathatóak olyan dolgok, ame- 
lyeknek sosem kellett volna más fülébe jutniuk. A hidak 
megnehezítik ezt a tevékenységet, ám teljes biztonságot 
nem nyújtanak. A hidak azonban okosak, így meg tudjuk 
mondani nekik, hogy milyen helyzetben mit továbbítsa- 
nak, illetve mit ne továbbítsanak. Ezzel megnövelik a há- 
lózat stabilitását is, hiszen védelmet nyújtanak a meghi- 
básodott állomás által folyamatosan a csatornára bocsátott 
szeméttől, illetve a hálózat megbénítását célul maguk elé 
tűző rosszakaróktól. 


Hidak IEEE 802 szabványú hálózatok között 

Még az Ethernet bemutatása előtt megemlítettük, hogy 
többféle LAN megvalósítás létezik. Ezek a megvalósítások 
mind szabványosítottak, azaz működésük a legapróbb rész- 
letekig dokumentálva van, és minden ilyen hálózat köteles 
betartani a szabványban leírtakat. A világ legnagyobb mű- 
szaki szakmai szervezete, az IEEE (Institute of Electrical 
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and Engineers) többféle szabványt készített helyi hálózatok- 
hoz, amelyek IEEE 802-es szabványokként híresültek el. Az 
előző részben a 802.3-on (Ethernet) kívül bemutattunk más 
szabványokat is. Ezek a szabványok csupán a fizikai és az 
adatkapcsolati réteg megvalósításában különböznek, onnan 
felfelé kompatibilisek egymással. 

A gond azonban pont az, hogy a különböző szabvá- 
nyok adatkapcsolati rétegei nem kompatibilisek egymás- 
sal. A hidaknak tehát valahogy át kell tudniuk alakítani 

a rajtuk átmenő forgalmat úgy, hogy az a célhálózatban 
tovább tudjon haladni. Ha úgy tetszik, a híd egy olyan 
eszköz, amely biztosítja a keretek számára egy másik 
típusú hálózatba történő átjárást. Ez azonban egy nagyon 
veszélyes út. 

Rögtön az első probléma, hogy két összekapcsolt hálózat 
nem biztos, hogy ugyanolyan sebességgel üzemel. Amikor 
egy gyorsabb hálózat küldi keretek sorozatát a lassabb fe- 
lé, akkor a híd nem tudja azt ugyanolyan gyorsan továbbí- 
tani. Amíg egy keret vár a továbbításra, addig a híd belső 
memóriájában kap helyet. Minden memória véges, ha 

a gyorsabb hálózatról folyamatosan érkeznek az adatok, 
akkor előbb-utóbb betelik a puffer, és a hídnak meg kell 
szabadulnia pár kerettől. Ugyanez lehet a helyzet, ha egy 
leterhelt Ethernet hálózat felé továbbítunk. A vezérjeles 
hálózatoknál a terhelés nem jelenthet puffer-túlcsordulást, 
hiszen biztosítva van, hogy a híd szabályos időközönként 
mindig adni tudjon. 

Másik probléma, hogy a híd a hálózatban torlódási pont 
lehet. Ez nem csoda, hiszen minden szabvány más keret- 
formátummal dolgozik, tehát a beérkező kereteket át kell 
alakítani és újból ki kell számolni az ellenőrző-összeget, 
ez pedig időbe telik. Miért baj ez? Tegyük fel, hogy a há- 
lózati réteg egy hatalmas üzenetet ad át az adatkapcsolati 
rétegnek. Mivel a kereteknek van egy maximális méretük, 
ezért ezt az üzenetet több keretre kell szabdalni, majd 
azokat sorban továbbítani. Ezeket a kereteket a hídnak 
egyenként kell átalakítania. Kellően sok keret esetén az 
átalakításra fordított idő olyan nagy lehet, hogy a forrás- 
állomás nyugtára váró időzítője lejár, és ismét elkezdi 
sorban küldeni a kereteket. Ezeket a hídnak megint csak 
át kell alakítania. Előfordulhat, hogy a forrás beleun az 
állandó ismételgetésbe, és hibaüzenetet dob, miszerint 

a célállomás nem válaszol. A probléma pedig nem is 

a címzettel van. 

A legsúlyosabb bajok forrása azonban a különböző ke- 
retméretek. Nyílván addig nincs gond, amíg egy olyan 
hálózatba továbbítunk kereteket, ahol a maximális méret 
nagyobb, mint a küldő hálózatban. Fordított esetben 
azonban az ésszerű teendő az lenne, ha a túl nagy keretet 
feldarabolnánk. A probléma azonban az, hogy az adat- 
kapcsolati protokollok nem támogatják a keretek össze- 
vissza szabdalását. Amikor egy állomás elküld egy kere- 
tet, akkor két esettel számol: vagy épségben megérkezik 
a célállomáshoz, vagy valahol elveszik útközben. De arra 
álmában nem gondol, hogy egy híd feldarabolja. Hiszen 
akkor ő egyet küldött, de a cél kettőt kap. Persze nem 
lenne túl nehéz ezeket a protokollokat alkalmassá tenni 

a feldarabolt keretek kezelésére, csak épp a 802-es szab- 
ványban ez nem szerepel. Így nem létezik megoldás. 
Illetve létezik: ha valaki egy olyan keretet küld, amelyet 
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a célhálózat nem tud elfogadni, akkor a híd egyszerűen 
eldobja. Ez azonban nem túl megnyugtató megoldása 

a problémának. 

Ha 802.4 (vezérjeles sín) hálózatról adunk 802.3 felé, akkor 
két további probléma is felmerül. Az első természetesen 

a prioritás. Az Ethernet hálózatokban az állomások nem 
rendelkeznek prioritással, míg a 802.4 esetében van ilyen 
szolgáltatás. Persze ez csak akkor jelenthet problémát, 

ha a két, egymással kommunikáló 802.4-es hálózat között 
van egy 802.3-as is. Ebben az esetben sajnos a keretek 
prioritását nem lehet megőrizni. 

Másik megoldhatatlan problémáért az ideiglenes vezér- 
jelátadás nevű szolgáltatás okolható. Ez arra való, hogy ha 
egy 802.4-es hálózatban küldünk egy keretet, akkor a célál- 
lomásnak lehetősége nyílik arra, hogy visszakapja a vezér- 
jelet ahhoz, hogy a nyugtát visszaküldhesse. Amikor egy 
ilyen keret érkezik a hídhoz, akkor annak komoly lelkiisme- 
reti kérdéssel kell megbirkóznia: vagy hazudik, és vissza- 
küld egy hamis nyugtát a feladónak, vagy becsületes mó- 
don nem szól semmit, csak továbbítja a keretet. Mind a ket- 
tő nagyon veszélyes, nehéz eldönteni, hogy melyik a jobb 
megoldás. Átverni a feladót nem bölcs dolog, főleg úgy, 
hogy elképzelhető, a célállomás nem is működik. A kere- 
tet nem nyugtázni is merész húzás, hiszen a feladó meg- 
elégelheti a dolgot egy , célállomás halott" hibaüzenettel. 
Tökéletes megoldás erre sem létezik. 

Amikor 802.3-ról 802.4-re szeretnénk egy keretet átját- 
szani, akkor ott csak a már említett prioritás okozhat 
gondot. Pontosabban az, hogy milyen prioritást állít- 
sunk be az átküldött kerethez. Talán a legjobb taktika 

az, ha mindig a legmagasabb fokú prioritást rendeljük 
az átmenő keretekhez, mivel feltehetően az már úgyis 
késleltetésben van. 

Ha két 802.4-es hálózatot szeretnénk egy híddal összeköt- 
ni, akkor szintén szembetaláljuk magunkat az ideiglenes 
vezérjelátadás problémájával. Ilyenkor a hídnak nagy 
szerencsejátékosnak kell lennie. Ha ugyanis úgy hozza 

a sors, hogy a keretet egyből tudja továbbítani, akkor van 
rá esély, hogy a nyugta időben megérkezhessen. Ha még- 
sem alakulnak úgy a dolgok, akkor csalni kell: a keret prio- 
ritását meg kell növelni. Ezzel lerövidíthetjük a nyugta 
célbaérkezésének idejét. 

Nem kérdés, hogy elég sok problémával kell szembenéz- 
nünk akkor, amikor két hálózatot egy híddal szeretnénk 
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összekötni. De mi a helyzet akkor, ha nem csak két, ha- 
nem több LAN-t és több hidat tartalmazó összekapcsolt 
hálózatunk van? Nos, erre is létezik IEEE szabvány, de 
hasonlóan a hálózatokhoz, itt is több (egész pontosan 
kettő) van, amelyek természetesen nem kompatíbiliesek 
egymással. 


Transzparens/feszítófás hidak 

Ezek a hidak abban a szellemben készültek, hogy bármiféle 
hardveres, illetve szoftveres beállítás nélkül telepíthetőek 
legyenek. Ezt szó szerint úgy képzelhetjük el, hogy amint 
bekötjük a hidat a hálózatba és bekapcsoljuk, a rendsze- 
rünk máris működik. Nem kell sem a hidat, sem az állomá- 
sokat felkonfigurálnunk. Azért nevezzük ezeket transzpa- 
rens (átlátszó) hidaknak, mert az állomások számára látha- 
tatlanok, ők ugyanúgy látják egy másik hálózat állomásait, 
mintha közös LAN-ban lennének. Amikor egy keret meg- 
érkezik, nem tudhatjuk, hogy útja során hány hídon ment 
keresztül, azaz hány híd van köztünk, és a velünk kapcso- 
latban lévő állomás között. 

Hogy megérthessük a transzparens hidak működését, 
tekintsünk a 3. ábrára. Itt négy LAN-t látunk három híddal 
összekötve. Tegyük fel, hogy az JA gép keretet küld az 1B- 
nek. Mivel ezek egy szegmensen vannak, így a B1 híd a ke- 
retet biztosan eldobja. Most nézzük azt az esetet, ha a keret 
címzettje 3B, amely egy másik szegmensen van. A hídnak 
most továbbítania kell a keretet, csak az a kérdés, hogy ho- 
hogy a keret címe alapján melyik végpontjára kell átjátsza- 
ni. Látja, hogy a 3B gép a hármas szegmensen van, így to- 
vábbítja a megfelelő portra. Fontos, hogy a táblázat nem azt 
mondja meg, hogy melyik szegmensen van a célállomás, 
hanem azt, hogy merre kell irányítani. Ha a címzett az 5C 
lenne, akkor is ezen a porton menne tovább a keret, csak 

át kell még mennie két másik hídon. De ezzel a B1 hídnak 
nem kell foglalkoznia. 

De azt mondtuk, hogy a transzparens hidak semmiféle be- 
állítást nem igényelnek. Mégis honnan tudják, hogy merre 
kell továbbítani az egyes kereteket? Valóban, kezdetben az 
összes híd táblázata üres. Ha tehát jön egy olyan keret, 
amelyiknek a címzettjét nem ismerik, nem tehetnek mást, 
mint hogy az összes kimeneten továbbítják (kivéve azt a 
portot, amelyikről a keret érkezett). Ezt úgy is mondjuk, 
hogy a hidak elárasztják a hálózatot. Ezután megjegyzik, 





























5. ábra 


hogy ennek a keretnek ki volt a feladója, és melyik LAN 
felől érkezett. Ha a későbbiekben egy olyan keret érkezik, 
amelynek a címzettje a kérdéses állomás, akkor már tudni 
fogják, hogy azt melyik kimenet felé kell irányítani. Ahogy 
egyre több keret érkezik, úgy fogják ismerni egyre részle- 
tesebben a hálózat felépítését. Ezt az algoritmust hátrafelé 
tanulásnak nevezzük. 

Egy hálózat felépítése azonban ritkán állandó, a lelkes 
rendszergazdák egyfolytában átalakítják. Például új hi- 
dakat telepítenek, régieket távolítanak el, és az állomáso- 
kat az egyik LAN-ból a másikba költöztetik. A hidaknak 
ezért folyton naprakész (sőt percre pontos) információval 
kell rendelkezniük a hálózat aktuális állapotáról. Ezért 
fontos tudniuk, hogy egy adott cím melyik időpontban 
került a táblába. Ha érkezik egy keret, amelynek forrása 
már szerepel a táblában, akkor annak időpontját a híd az 
aktuális időpontra írja felül. Ezenkívül minden, néhány 
percnél öregebb bejegyzést a hidak törölnek. Ezzel elér- 
hető, hogy ha egy állomást elköltöztetünk a hálózat egy 
teljesen más pontjába, akkor is perceken belül visszaáll 

a normális működés. 

Tekintetünket szegezzük most a 4. ábrára, ahol csupán 
csak két LAN van, viszont a rendszergazdák biztosra 
akartak menni, és két híddal kötötték össze a szegmense- 
ket, hogy meghibásodás esetén se legyen semmi problé- 
ma. Tegyük fel, hogy a felső LAN egyik állomása egy 
olyan keretet bocsát útnak, amelynek a címzettje mindkét 
híd számára ismeretlen. Nincs mit tenni, mindketten el- 
árasztanak, azaz a kérdéses keretet mindketten az alsó 
LAN-ra másolják. Ezután nem sokkal a bal oldalt lévő 
híd felfedezi a jobb oldali híd által átjátszott keretet, 
amit ő visszamásol a felső LAN-ra, amit majd ismét 

a jobb oldali fog ismét az alsó LAN-ra másolni. Ennek 

a folyamatnak sohasem lesz vége. 

Mitől alakulhatott ki ez a roppant kellemetlen helyzet? 
Hát azért, mert hurok volt a hálózatunkban. Ezért a hidak- 
nak valahogy egyeztetniük kell egymással, és logikailag úgy 
átalakítani a hálózatunk topológiáját, hogy egy LAN-hoz 
csak ,egy út vezessen". 
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Képzeljük el úgy a hálózatunkat, mint egy olyan gráf, 
amelynek a csúcsai a LAN-ok. Erre láthatunk példát az 

5. ábrán, ahol a változatosság kedvéért vezérlőjeles gyűrűs 
hálózatokat kötöttünk össze egymással. Két csúcs akkor 
legyen egymással összekötve, ha össze vannak kapcsolva 
híddal. Jelen esetben minden csúcs össze van kötve min- 
denkivel. A feladat az, hogy egy körmentes, ám továbbra 
is összefüggő gráfot kapjunk, amely tartalmazza az ere- 
deti gráf összes csúcsát. Ez az eredeti gráf úgynevezett 
feszítőfája (spanning tree). A feszítőfára az jellemző, hogy 
minden csúcsból minden csúcsba pontosan egy út vezet. 
Egy ilyen hálózati topológiában nem fordulhatna elő az 
előbb említett eset. 

A hidaknak tehát egymás között meg kell állapodniuk 

a feszítőtában. Ehhez maguk közül ki kell választani vala- 
kit, aki a fa gyökerét fogja képezni. Erre egy elég frappáns 
megoldást alkalmaznak: minden híd megmondja a saját 
egyedi sorozatszámát. Akié a legkisebb, az lesz a gyökér. 
Ezután meg kell határozni azt a fát (a feszítőfát), amely 
minden LAN-hoz a lehető legrövidebb utat tartalmazza. 
Ezt a fát természetesen újra kell számolni, ha a hálózati 
topológia megváltozik, például új híd kerül telepítésre. 

A feszítőfát kiszámoló osztott algoritmus egyébként soha- 
sem állle, így a feszítőfa azonnal érzékelhető. 

Az így kialakított új hálózati topológiánkban az összes 
LAN biztosan benne marad, de nem biztos, hogy az 
összes híd is! Amikor a fizikai topológiát ábrázoló gráf- 
ból egy élet elhagyunk, az azt jelenti, hogy az adott él- 
hez tartozó hídnak blokkolnia kell azt a két kimenetét, 
amely az élhez tartozó két csúcsot (LAN-t) összeköti. 

Ha egy híd minden olyan használatban lévő portját blok- 
kolta, akkor ő nem vesz tovább részt az adatforgalom 
továbbításában. Ez a helyzet az 5. ábrán is. Az ott látható 
gráfból egyféleképpen készíthetünk feszítőfát: egy tetsző- 
leges élt törlünk, azaz megszüntetjük a kapcsolatot két 
tetszőleges LAN között. Jelen esetben az 1. és a 2. között, 
de bármelyiket is választjuk, egy híd mindenképp mun- 
ka nélkül marad. 

Látható tehát, hogy a transzparens hidak képtelenek ki- 
használni a teljes rendelkezésre álló sávszélességet. Nem 
úgy mint a következő hídcsoport. 


Forrás által irányított hidak 

Ezek aztán tényleg kihasználják a sávszélességet, habár 
van egy buktatója a dolognak, de erről majd kicsit később. 
A működési elv azzal a nehezen teljesíthető feltételezéssel 
él, hogy minden állomás, aki üzenetet szeretne küldeni egy 
másik állomásnak, pontosan tudja, hogy a címzettel egy 
szegmensen van-e, vagy sem. Ha nincs, akkor viszont tud- 
ja, hogy miként lehet (mely hidakon keresztül) eljutni abba 
a hálózatba. 

A forrás általi forgalomirányítás (source routing) könnyebb 
megértéséhez ismét segítségünkre lesz a 3. ábra. Ha az 1A 
szeretne mondani valamit az 1B-nek, akkor a keret címé- 
nek utolsó helyiértékű bitjét 0-ra állítja, mivel egy szeg- 
mensen vannak. Ekkor a B1 híd nem foglalkozik a keret- 
tel. Ha azonban az 5C gépnek szeretne küldeni, akkor en- 
nek a bitnek az értéke 1 lesz, és a keret fejlécébe beszúrja 
a pontos útvonalat is. Ahhoz, hogy ezt az útvonalat le le- 
hessen írni, minden LAN-nak rendelkeznie kell egy egye- 
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6. ábra 


di címmel. Ugyanez a helyzet az összes ugyanahhoz 

a szegmenshez kapcsolódó híddal is. Tehát a B1 és B2 
hidak címének különbözőnek kell lennie, de a B] és B3 
címe megegyezhet. Az útvonal tehát egy olyan sorozat 
lesz, amelyben felváltva szerepel egy híd és egy LAN cí- 
me. Az 1A - 5C útvonal tehát a következőképp fog kinéz- 
ni: B1, Seg3, B2, Seg4, B3, Seg5. Amikor egy híd megkap 
egy ilyen keretet, akkor belenéz az előírt útvonalba, és 
megkeresi benne annak a LAN-nak a címét, ahonnan 

a kérdéses keret érkezett. Ezután megnézi, melyik híd 
címe áll mögötte. Ha ez a cím a saját címe, akkor tovább- 
küldi az előírt szegmensre. 

A kérdés már csak az, hogy honnan tudhatják az állomá- 
sok azt, hogy a cél felé pontosan milyen út is vezet. Sőt, 
nem elég bármelyik útvonalat ismerni, ahhoz hogy a do- 
log valóban hatékony legyen, a legeslegrövidebb utat kell 
megtalálniuk. 

Amikor egy állomás nem ismeri a címzettjének pontos 
helyét, akkor egy úgynevezett felkutató keretet (discovery 
frame) bocsát útnak. Ezeket adatszórással továbbítja, és 
minden híd minden irányba továbbítja, tehát biztosan 
megérkezik az összes LAN-ra. Amikor a címzett rádöbben, 
hogy valaki holléte felől érdeklődik, egy válaszkeretet küld 
vissza. Ahogy ez a keret visszafelé indul, minden olyan híd, 
amelyen áthalad, beleírja azonosítószámát. Így amikor 
visszaér, az állomásnak lehetősége nyílik megvizsgálni a 
visszafelé vezető útvonalat, amelyből könnyedén kiszámít- 
ható a célhoz vezető legoptimálisabb útvonal. 

A már említett buktató akkor jelentkezik látványosan, 

ha a hálózatunk topológiája hasonló a 6. ábrán bemutatott- 
hoz. Itt a LAN-okat sorba egymás után kötöttük, minden 
egyes LAN-t három híd kapcsol össze egymással. Az 1-es 
állomás a 2-es pozíciójáról szeretne többet megtudni, ezért 
kutató keretet indít útnak. Mivel ezeket a kereteket az 
összes híd továbbítja, ezért aszomszédos LAN-on már há- 
rom kutató keret lesz jelen, a 3-on kilenc, a 4-en pedig 27. 
Ez bizony exponenciális ütemben zajló növekedés, tehát 
10 LAN esetében majdnem 20 ezer, 20 LAN-nál pedig 
több mint 1 milliárd keretet jelent. Talán nem kell ecsetel- 
ni, hogy ez mekkora terhelést is jelent. Ezért is hívják ezt 
a jelenséget keretrobbanásnak. 


16 Linuxvilág 









Hálózati hardver 


4. OSI réteg (Átviteli réteg) 
ÁTJÁRÓ 






SNA s TCPAP 
IPX/SPX n TCP/IP 
SNA a DECnet, stb. 


3. OSI réteg (Hálózati réteg) 


ÚTVÁLASZTÓ 








fi) HUB KER 
s 7 
MESET. 7 
—i Megosztott közeg Ez m- Dedikált kapcsolatok "esel, 
ASZ — Ethernet, Token Ring SE. EZ. KapcsoltEthernet SSE 
9 Kapcsolt Token Ring, ATM 
HÍD 


es Ez sz 







tása Ethernet és 
Token Ring között 








Nagytávolságra 
küldött jelek 
regenálása 









LAN szegmens LAN szegmens 








7. ábra 


Felmerülhet a kérdés, hogy a transzparens hidakat miért 
nem veszélyezteti a keretrobbanás, miközben ők is ugyan- 
ezt csinálják azokkal a keretekkel, amelyeknek a címzettje 
ismeretlen. Valójában ott is ugyanez a folyamat játszódik le, 
csak nem árasztják el velük az egész hálózatot, hanem kizá- 
rólag a feszítőfa mentén küldik tovább. Ez pedig csak lineá- 
ris ütemben történő növekedés, amely nem jár ilyen drasz- 
tikus végeredménnyel. 


Hálózati eszközök — összefoglalás 

Sorozatunk e részének végén érdemes egy gyors összefog- 
lalást végezni azzal kapcsolatban, hogy milyen hálózati esz- 
közöket is ismerünk idáig, és ezeknek pontosan mi a fel- 
adatuk. Ehhez hasznos segítséget nyújt a 7. ábra. Az átjáró 
(gateway) és az útválasztó (router) még ezidáig nem szere- 
pelt, mivel ezek a felsőbb, eddig még nem tárgyalt rétegek- 
ben tevékenykednek. Fontos, hogy hiába végez a híd forga- 
lomirányítást, illetve üzemel , átjáróként" különböző szab- 
ványú hálózatok között, nincs köze az útválasztóhoz és az 
átjáróhoz. 

A hub a fizikai rétegben tevékenykedik és nagyon buta 
eszköz: ami az egyik portján bemegy, az kijön a többin. 

A kapcsoló (switch) ennél sokkal okosabb, hiszen képes az 
adatkapcsolati réteg adategységeit, a kereteket olvasni, így 
csak arra a kimenetre küldi az adatot, ahol a címzett talál- 
ható. Nem így a jelismétlő (repeater), amely a hubbal van 


nm 


egy szinten": ő is csak ismételni tudja a bejövő jeleket, 
igaz, felerősíti azokat. 
A következő részben a nagy sebességű hálózatokról és 


műholdakról lesz szó. 


Garzó András 
garzo(vinterware.hu 











Fénysebességgel 


Most már olyan űrhajót is tudunk tervezni, ami a vöröseltolódás után is jól néz ki. 


Relativitás, csillagok és sok minden más. 


gazad van, Francois, a számítógépek és az operációs 
n] rendszerek komoly utat jártak már be. Nemcsak az 

a szerencse ért bennünket, hogy már ma használhatjuk 
a jövő operációs rendszerét, de minden eddiginél gyorsabb 
gépek tudását élvezhetjük. Mit is mondjak, talán némi elfo- 
gult szeretettel gondolok vissza első x86 alapú számítógé- 
pemre. Egy felturbózott XT volt, a processzora kereken 
10 MHz-en ment. Kisebb vagyont költöttem arra, hogy 
a memóriáját 640 kB-ról 1024 kB-ra bővítsem; emlékszem, 
egy maroknyi lapkát kellett beledugdosnom az alaplapon 
lévő foglalatokba. 
Ouoi? Természetesen, mon ami, hiába volt jó kis gép akkori- 
ban, nem kívánok lemondani a kor vívmányairól. Az olyan 
lenne, mintha a Linuxot másik operációs rendszerre cserél- 
ném. Tudod, Francois, érdekes elmélázni azon, hogy milyen 
messzire jutottunk — a megahertzes processzorokból giga- 
hertzesek lettek, alig néhány év alatt! Vajon mi lesz majd tíz 
év múlva? Igen, lehet, hogy túllépjük a fénysebességet is, 
de attól tartok, mon ami, az azért egy kicsit még várat ma- 
gára. Viszont adtál egy jó ötletet. 
Mon Dieu! Már itt is vannak a vendégeink! A borospincébe, 
immédiatement! Indíts az északi szárnyba, ott van a leg- 
újabb szállítmány Bordeaux-ból, Henri tegnap hozta. Találsz 
ott néhány láda 2000-res Cháteauneuf-du-Pape-ot is. Bocsás- 
satok meg, mes amis. Foglaljatok helyet, helyezzétek maga- 
tok kényelembe. Francois és jómagam arról csevegtünk, 
hogy az utóbbi években mekkorát fejlődött a világ. Készsé- 
ges felszolgálóm felvetette a fénynél is gyorsabb számítógé- 
pek ötletét, mely talán mai témánk, a nagyteljesítményű 
számítások mindenható eszköze lenne. Hiába lennének 
azonban az adatokat a fénysebességnél is gyorsabban szállí- 
tó gépeink, mi magunk továbbra is képtelenek lennénk ak- 
kora információmennyiséget befogadni. Egy biztos, a leg- 
újabb Linuxvilág olvasgatása közben nem fogjuk látni 
összecsúszni a csillagokat. 
Sebesség tekintetében a fényt semmi sem győzheti le, ha- 
csak valamiféle rejtélyes anyag-antianyag motorral és né- 
mi dilítium kristállyal nem. Ugyanezt az érzést élhetjük 
át, ha beállítunk magunknak egy képernyőkímélőt, és az 
xscreensaver kínálatából a rocks, azaz sziklák nevűt választ- 
juk, esetleg az OpenGL alapú space, űr nevűt a KDE saját 
listájáról. Az, hogy mit látnánk a fénysebesség megközelíté- 
se közben, a tudományos-fantasztikus filmek örök témája, 
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1. ábra Vajon mi történne egy űrhajóval, miközben megközelítené 
a fénysebességet? 


ám nagyon valószínű, hogy a valóságban soha nem tudjuk 
meg. Éppen ez adta az ötletet Daniel Richard G. Light 
Speed! nevű programjához, amely azt szemlélteti, hogy mit 
látnánk, ha egy tárgy megközelítené a fénysebességet. 

A program számos valódi hatást vesz figyelembe, mint pél- 
dául a Lorentz-összehúzódás, a vörös/kék Doppler-eltoló- 
dás, az orrlámpa-effektus és az optikai elhajlás. A Light 
Speed! webhelyének About lapján mindegyik hatás leírását 
megtaláljuk. 

Mes amis, biztos vagyok benne, ez a bor ízleni fog — való- 
ban testes ital, fekete gyümölcsök aromájával, sejtésnyi ká- 
véval és hosszan tartó utóízzel. Kortyolgassátok, amíg mi 
felgyorsítunk fénysebességre. A fordítás rendkívül könnyű. 
Jó, ha tudjuk, szükségünk lesz az OpenGL vagy Mesa fej- 
lesztői könyvtárakra, valamint a gtkglarea könyvtárakra. 
Innen már csak egy egyszerű kitömörítés és lefordítás 
következik öt lépésben: 


tar -xzvf lightspeed-1.2a.tar.gz 
cd lightspeed-1.2a 

. /configure 

make 


su -c "make install" 
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A program indításához a lightspeed parancsot kell kiadni. 
Egy ablaknak kell megjelennie, benne pedig egy három di- 
menziós rácskockának. A jobb felső ablakban lévő mezőbe 
lehet beírni a sebességet, méter/másodpercben. Mérsékelten 
magas értékkel indítsunk, később a felfelé és a lefelé nyíllal 
növelhetjük és csökkenthetjük a sebességet. Ha lenyomjuk 
az Entert, a tárgy a megadott sebességre gyorsul, az ebből fa- 
kadó hatásokat pedig az ablakban követhetjük figyelemmel. 
Egy a fénysebesség közelébe kerülő, fokozatosan eltorzuló 
kocka roppant érdekes dolog, ám ha a menüsorban a File 
(Fájl) majd a New Lattice (Új rácsozat) parancsra kattin- 
tunk, végül megadjuk a három dimenzióbeli pontok szá- 
mát, akkor bonyolultabb alakzatokat is előállíthatunk. A va- 
lódi kérdés az, vajon mi történne egy űrhajóval, ha megkö- 
zelítené a fénysebességet? Micsoda szerencse, hogy itt van 
nekünk a Light Speed! A webhelyről objektumokat is le le- 
het tölteni, érdemes megpróbálkozni vele. Három objektu- 
mot találunk, köztük a Star Trek Voyager (1. ábra) modelljét. 
Ha másik modellt szeretnénk kipróbálni válasszuk a File 
(Fájl) menü Load Object (Objektum betöltése) pontját. 

Még jobban szórakozhatunk, ha ellátogatunk a 3-D Cafe ol- 
dalra (lásd a forrásokat), ahol rengeteg további három di- 
menziós modellt és hálót találunk. Ne csak űrhajókat pró- 
báljunk ki, egy fénysebességgel haladó versenyautó legalább 
olyan érdekes. Ne feledjük, hogy csak 3DS (3D Studio) vagy 
LWO (LightWave 3D) kiterjesztésű modelleket tudunk hasz- 
nálni. Remek dolog eljátszani a gondolattal, hogy mi történ- 
ne ilyen körülmények között, de legalább ennyire szeretne 
mindannyiunk tíz warp sebességgel száguldani az űrben, 
bámulni az egymásba tolódó csillagokat, majd még a követ- 
kező borosüveg kiürülése előtt megérkezni egy távoli világ- 
ba. Ilyesfajta kirándulást a Chris Laurel-féle Celestiával te- 
hetünk. A Celestia segítségével többek közt felfedezhetjük 
saját naprendszerünket, több mint százezer csillagra láto- 
gathatunk el és megismerhetjük a Földről indított különfé- 
le űrszondák sorsát. Az oldalról forrást is letölthetünk, de 
Mandrake, SuSE és egyéb terjesztések alá binárisokat is talá- 
lunk. Ha nem találjuk a saját rendszerünkhöz való bináriso- 
kat, akkor sincs gond. A program OpenGL alapú, ezért szük- 
ségünk lesz a 3D könyvtárakra, de a fordítás ismét csak az öt 
lépésből álló, gyermekien egyszerű folyamat: 


tar -xzvf celestia-1.3.1.tar.gz 
cd celestia-1.3.1 


. /configure 
make 
su -c "make install" 


Futtatásához a parancssorból vagy a parancsindítóból adjuk 
ki a celestia parancsot. Néhány billentyű szerepét nem árt 
ismerni, így ugyanis sokkal érdekesebb lesz az utazás. Az L 
betűvel tízszeresen gyorsíthatjuk az időt. Ekkor űrbéli uta- 
zásunk a hivatkozási pontként kiválasztott tetszőleges ob- 
jektumhoz lesz viszonylagos. A K lenyomásával lelassíthat- 
juk az időt, ha túl gyorsan haladnánk. Az ALr-C billentyű- 
kombináció a Celestia böngészőjét indítja el, amellyel kü- 
lönféle objektumok közül tudunk választani. A képernyő 
alján négy választógomb jelenik meg. Kattintsunk a With 
planets (Bolygókkal) gombra, ekkor megjelenik az ismert 
bolygókkal rendelkező csillagok listája. Szeretnénk elláto- 
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2. ábra A Mars körül keringő űrszonda követése 











3. ábra A KStars online adatbázisokból — mint amilyen Hubble-é — 
is képes képeket beemelni 


gatni az 51 Pegasi körül keringő bolygóra? Kattintsunk az 
egér jobb gombjával az objektum nevére, válasszuk a Goto 
(Ugrás) parancsot, majd csatoljuk be az öveket! A fénynél is 
gyorsabban juthatunk el ebbe az idegen világba. Ha már ott 
vagyunk, kattintsunk rá az 51 Pegasi csillagra, válasszuk 

a Follow (Követés) parancsot - így a csillagnál maradva vizs- 
gálhatjuk meg a bolygó pályáját. 

A gombokkal a csillagok megjelenítési módját is megadhat- 
juk, az apró tűszúrásoktól kezdve a kisméretű foltokon ke- 
resztül egészen részletesen megrajzolt korongokig változtat- 
hatjuk a képüket. Ha az összes billentyű szerepét meg szeret- 
nénk ismerni, akkor kattintsunk a Settings (Beállítások) menü 
Configure Shortcuts (Gyorsbillentyűk beállítása) parancsára. 

A Celestia nagyszerű eszköz, ha kényelmesen ücsörögve 
szeretnénk felfedezőútra indulni; valóban megéri letölteni. 
A csillagokon és a bolygókon túl a közeli égitestek körül ke- 
ringő űrszondákra, például a Mars Global Surveyorra is el- 
látogathatunk. Próbáljunk az űrszonda felé fordulni, kat- 
tintsunk a Marsra, majd válasszuk a Follow (Követés) paran- 
csot. (2. ábra) Most gyorsítsuk fel az idő múlását. Az adatbá- 
zisban számos nagyobb aszteroida is szerepel, ha gondol- 
juk, akkor ellátogathatunk például az Erosra. 

Ha a fénysebességen túli űrbéli utazgatás túlságosan felfor- 
gatja a gyomrunkat, esetleg hatására arcunk egészen újsze- 
rű, zöldes árnyalatot vesz fel, talán próbáljunk inkább a Föl- 











dön maradva foglalkozni a végtelen rejtelmeivel. Miért nem 
biztosan álló székünkből szemléljük a csillagokat és bolygó- 
kat? A legkönnyebben ezt Jason Harris KStars programjá- 
val tehetjük meg. A KStars egy igazi planetáriumot varázsol 
asztalunkra. Mivel a KStars része a KDE környezetnek 

— a kdeedu csomagban található —, nem kell túl sokat keres- 
gélnünk, hogy rábukkanjunk. A csomaggal kapcsolatos új- 
donságokról a weblapról tájékozódhatunk. 

A KStars egyszerűen lenyűgöző, de ne gondoljuk, hogy 
egyszerű játékszer. A bolygók, 130 ezer csillag, 13 ezer 
mélyűrbéli objektum (bolygók és aszteroidák) adatbázisával 
a KStars valóságos csillagászati kincsesláda. Segítségével 
könnyedén beazonosíthatjuk az éjszakai égbolton látható 
csillagok, galaxisok, csillagködök és egyebek helyzetét. Pon- 
tosan beállíthatjuk, hogy mit akarunk megjeleníteni, rákö- 
zelíthetünk az objektumokra és — nekem ez a kedvencem — 
hálózati forrásokból képeket is tölthetünk le, például 

a Hubble vagy a Space Telescope Science Institute adatbázisá- 
ból. Elég az egér jobb gombjával a kiszemelt objektumra 
kattintanunk, a felbukkanó ablakban megtekinthetjük rész- 
letes adatait, valamint nagyfelbontású képekre mutató hi- 
vatkozásokat is kapunk, ha vannak ilyenek. A 3. ábrán 

a KStars képernyője látható, miközben a Trifid Nebula ada- 
tait jeleníti meg. 

A KStars indításkor feltételezi, hogy az angliai Greenwich- 
ben vagyunk. Nyilván ezen változtatni szeretnénk, ehhez 
kattintsunk a Location (Hely) menü Geographic (Földrajzi) 
parancsára. Egy párbeszédpanel jelenik meg, egy világtér- 
képpel kiegészítve. Kattintsunk nagyjából arra a területre, 


ahol élünk. Ekkor a térképtől jobbra földrajzi pontok egy 
listája jelenik meg. Válasszuk ki a megfelelőt, majd kattint- 
sunk az OK gombra. Ha tudjuk, hogy pontosan mi lakhe- 
lyünk hosszúsági és szélességi koordinátája, akkor az ablak 
alján ezt is megadhatjuk. 

A KStars jóval többet tud, mint amiről egy ilyen rövid látoga- 
tás alatt szólhatnék. Képes például saját teleszkópunkat ve- 
zérelni, a kívánt objektumokra irányítani és azokat követni. 
Akit érdekel a csillagászati fényképezés, annak megemlíte- 
ném, hogy a KStars a CCD-k kezelésére is alkalmas. Noha ez 
a szolgáltatás jelenleg csak a Finger Lakes Instruments eszkö- 
Zeire terjed ki, a támogatást hamarosan bővíteni fogják. 

Mon Dieu! Bár a fény sebességét meg sem közelítettük, 
mégis gyorsan megtörtént. Igen, az órára gondolok, mes 
amis, ami bizony már zárórát mutat. Felfoghatatlan sebessé- 
gekről beszélünk, de közben ne feledjük el, milyen csodás 
egy holdfényes éjszakán hátradólni, és lassan kortyolgatni 
ezt a kiváló Cháteauneuf-du-Pape-ot. A következő alkalomig 
igyunk egymás egészségére, mes amis! A vötre santé! 

Bon appétit! 


Linux Journal 2004. november, 127. szám 


Marcel Gagné (mggagneOsalmar.com) 
Mississaguában, Ontario államban él. 

Ő a szerzője a Kiskapu kiadásában tavaly szep- 
temberben megjelent Linux-rendszerfelügyelet 
(ISBN 96-9301-40) című könyvnek. 
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A vagyoni jogi jogosultságok, 


avagy pénz beszél..." 


... a jogász meg mondja a magáét... mely szerint a vagyoni jogi jogosultságokkal 
tisztában lenni, minden szerző elengedhetetlen kötelezettsége. 


szerző joga, hogy a mű felhasználására bárkinek 
A engedélyt adjon, ezt szoftver esetében általában 

egy -— a számítástechnikai berkekben licenc néven 
ismert - felhasználási szerződés keretében teheti meg. 


A vagyoni jogi jogosult 

Tételezzük fel, hogy legújabb — kereskedelmi forgalomban 
szerzett? — , Handabanda" névre hallgató, füllentés-analizáló 
szoftverünk licencében azt találjuk, hogy a velünk szerződő 
jogosult nem Svindli Jimmy (aki egyébként a szerző), ha- 
nem a Víg Matróz és Társa Részvénytársaság (a továbbiak- 
ban VMT Rt.). Ennek az alábbi okai lehetnek: 


1. Jimmy a VMT Rt. munkavállalója, így az általa — mun- 
kaviszonyban - alkotott szoftverek vagyoni jogai auto- 
matikusan átszálltak az őt foglalkoztató cégre. 

2. A ,Handabanda" együttesen létrehozott műnek minő- 
sül, ami körülbelül annyit tesz, hogy a VMT Rt. kezde- 
ményezte és irányította a szoftver fejlesztését, és azt 
a későbbiekben saját neve alatt hozta forgalomba?. 

(A mű megalkotásában együttműködő szerzők hozzájá- 
rulásai pedig oly módon egyesültek, hogy azokat a ké- 
sőbbiekben nem lehet szétválasztani — azaz itt a fejlesz- 
tésben nem csak Jimmy, hanem a Kapitány, és a többiek 
is közreműködtek.) 

3. Az Rt. jogátruházás révén vált a szoftver jogosultjává. 
Ez a szerzés olyan további kérdéseket vet fel, hogy pél- 
dául milyen áron és milyen körülmények között cserél- 
tek gazdát a jogok. Az átruházás ugyanis nem történhe- 
tett szóbeli megállapodással, mert az semmis szerződés 
lenne, hasonlóan ahhoz az esethez, ha az Rt. képviselő- 
je, a Kocsma a három rozsdás szöghöz" nevű ivóban 
íratja alá a meglehetősen ittas Jimmy fiúval a szerződést, 
melynek keretében az - további 6 felesért — átengedi 
a kizárólagos jogokat. 


Bár ilyen szélsőséges példákkal a való életben nem nagyon 
találkozunk, mégis egyértelműen kirajzolódik a nagyobb 
vállalatok törekvése, mellyel a szerzőktől a lehető legalacso- 
nyabb áron próbálják a fejlesztéseket megszerezni. 


Vagyoni jogi ipi-apacs 

Induljunk ki abból, hogy az eljárás jogszerű volt, tehát a jo- 
gokat törvényes keretek közt szerzi meg a jogosult. Lássuk, 
pontosan mit is engedünk át ilyenkor. 

A mű felhasználási területeit két nagy csoportba soroljuk, 
ezek az anyagi és a nem anyagi felhasználási formák. 





A fenti felsorolás három, a szoftverekkel kapcsolatban kife- 
jezetten lényeges pontot tartalmaz, nevezetesen a többszö- 
rözést, a terjesztést és az átdolgozást. Ezekkel tehát ismer- 
kedjünk meg közelebbről is. 


! Ebben a részben főleg kereskedelmi forgalomban megjelenő szoftverekről lesz szó, ráadásul többnyire a szerző szemszögéből. A szabad illetve 


nyílt forráskódú társaikról külön írást szántam. 


szerződésről szóló cikkben írok erről, valamikor jövőre. 
Félreértés ne essék, ettől még a VMT Rt. nem lett szerző. 
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Ez szükséges kitétel, a jelenlegi szerzői jogi szabályok szerint, ugyanis csak ez a forma mentes az írásbeliség alól. Bővebben a felhasználási 


A táblázat többnyire a szoftverek szempontjából releváns jogokat tartalmazza. 











A többszörözés 

Ha épp nem a szoftverjogról szólna ez a sorozat, hanem 
valamilyen más szerzői alkotással hozott volna össze 
minket a véletlen, sok szempontból egyszerűbb lenne 

a helyzetünk. Létezik ugyanis a , magáncélú másolás" 
nemes intézménye, amely lehetővé teszi, hogy egyes mű- 
vekről (például film a tévében) külön engedély nélkül 
másolatot készítsünk. Azt persze nem mondanám, hogy 
ezt minden külön díj megfizetése nélkül tesszük, mert 

ez a megállapítás nem lenne helyénvaló. Az ilyen máso- 
latokért bizony fizetünk. 

Ez a díj hanghordozók esetében (például kazetta, CD, 
DVD) az úgynevezett , üreskazetta jogdíj", amit eleve 
minden egyes adat- vagy hanghordozó árába beépítenek. 
A másik ilyen - talán nem annyira közismert — ,védő- 
vám" a papír alapú tartalom többszörözést ellensúlyozó 
vreprográfiai jogdíj", amit korábban csak a fénymáso- 
lókra alkalmaztak, mostanra azonban - az internetes tar- 
talom egyre terjedő többszörözésére reagálva — egyes 
nyomtatókra is kiterjesztettek. Ezek a pénzek aztán 

egy precíz szabályozás szerint a szerzők között kerül- 
nek szétosztásra. 

Eddig ha az előbb vázolt gondolatmenetemet megpróbál- 
tam egy informatikussal megosztani, az mindig csúnyán 
kezdett el nézni rám. Hiszen miért is fizessen ő holmi — ál- 
tala nem is ismert szerzőknek — mikor a megvett CD-re jó 
eséllyel csak egy adatmentés kerül? Igazságtalannak és mél- 
tánytalannak érezte ezt az eljárást, mint ahogy valószínűleg 
az a kereskedő is háborog, aki csak számlanyomtatásra 
használja a lézernyomtatóját. Mit is lehet erre válaszolni? 
Talán azt, hogy ez a kisebb rossz. Gondoljunk csak bele, 
hová vezetne, ha a magáncélú másolás is engedélyköteles 
lenne, vagy esetleg teljesen tilos? Lényegesen csökkenne 
annak a lehetősége, hogy ismeretekhez jussunk vagy juttas- 
sunk másokat. A legegyszerűbb tehát az, ha hőbörgés he- 
lyett a kasszánál való sorbanállás alatt azzal a jóleső érzéssel 
készítjük elő a valamivel magasabb összeget, hogy — ha 
nem is teljesen jószántunkból - egy jó ügyet támogatunk. 
Érezzük magunkat inkább mecénásnak, mint becsapott, 
megsarcolt vásárlónak. 

A többszörözés szoftver esetében egyetlen , biztonsági má- 
solat" készítése erejéig tekinthető jogszerűnek. Értelemsze- 
rűen a biztonsági másolatról nem illik biztonsági másolatot 
készíteni, ,biztos ami biztos" alapon. Külön kérdést vet fel, 
hogy egy-egy teljes mentés készítése sérti-e ezt az elvet, hi- 
szen itt a többszörözés készítőjének nyilvánvalóan nem áll 
szándékában, hogy egy operációs rendszerről készítsen má- 
solatokat. Ő csak adatbázisokat akar — a megfelelő környe- 
zetbe illesztve — lementeni. Aztán hogy ezt adott esetben 
majd hogyan fogja megítélni egy bíróság egy eljárás során, 
nos azt nem tudhatjuk. Meglátásom szerint a jogsértés 
ilyenkor annyira csekély mértékű, amellyel kapcsolatban 
sem társadalomra való veszélyességet, sem pedig ténylege- 
sen a szerzőnél jelentkező kárt nem lehet kimutatni. 

A többszörözés jogának megsértése olyankor már sokkal 
nyilvánvalóbb, amikor elszedve a szomszéd kisfiú kétheti 
zsebpénzét adunk neki egy másolati példányt a legújabb 


csihi-puhi" játékszoftverünkből. Nyilván nincs az a bíró- 
ság, amelyik ezek után elhinné, hogy mi a törvény által en- 
gedélyezett másolati példányunkat a szomszédban akartuk 
tartani, mert az egy tucat tizenéves gyerek között nagyobb 
biztonságban van, mint a szobánkban a polcon. 


A terjesztés 

Először is tételezzük fel, hogy a mű nem egy vírus, vagyis 

a jogszerű terjesztésnek efféle akadálya nincs. Terjesztésnek 
minősül a mű eredeti példányának (szoftver esetében ez 
kevéssé valószínű) vagy többszörözött példányának (jelleg- 
Zetes terjesztési forma) hozzáférhetővé tétele a nyilvános- 
ság számára, amely történhet kereskedelmi forgalomba ho- 
zatallal, vagy forgalomba hozatalra való felkínálással. 

Egy számítógépes program törvény által nevesítve átruhá- 
zással, bérbeadással valamint az ország területére forgalom- 
ba hozatal céljából való behozatallal terjeszthető. Ez konk- 
rétan elidegenítést, ajándékozást, bérbeadást, kölcsönzést 
valamint importot jelenthet. 

A magyar szabályozás az általános rendelkezések között 
nevesíti a jogkimerülés feltételét, mely szerint, ha a mű- 
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példányt a jogosult vagy az ő kifejezett hozzájárulásával 
más adásvétellel vagy a tulajdonjog más módon történő 
átruházásával forgalomba hozta, a terjesztés joga az így 
forgalomba hozott műpéldány tekintetében - a bérbe- 
adás", a haszonkölcsön és a behozatal jogának kivételé- 
vel - a továbbiakban nem gyakorolható. Könyvek eseté- 
ben például ez teremti meg az antikváriumok létjogosult- 
ságát. Szoftverek vonatkozásában ilyesmit nem találunk... 
Legalábbis még nem. A hiány oka talán mindössze annyi, 
hogy eleddig senki sem keresete meg a bíróságot azzal, 
hogy szeretné már megunt szoftverét továbbértékesíteni, 
és ebben az arra jogosult őt megakadályozza. Talán fel- 
tűnne a bíróságnak, hogy az ilyen jellegű magatartás azon 
túl, hogy a szabad piacnak árt, erősen emlékeztet a joggal 
való visszaélésre is... 

Tapasztalatból tudhatjuk, hogy kereskedelmi forgalomba 
kerülő szoftverek licencei vagy teljes mértékben kizárják 

a továbbértékesítést, vagy soha megadásra nem kerülő 
engedélyhez kötik azt. 

Hasonló nehézségekkel szembesülhet az, aki cégek felszá- 
molásával foglalkozik, és a gépállománnyal megszerzi az 
azon futó szoftverekhez kapcsolódó jogosultságot is. Leg- 
alábbis, azt hiszi, hogy megszerezte. Hazánkban tudtommal 
ezen a téren nincs sem precedens értékű döntés, sem ehhez 
kapcsolódó per folyamatban. A németek egy lépéssel előt- 
tünk járnak, egy ottani bíróság már kimondta, hogy egy 
szoftver felhasználásának , továbbadását" ilyen módon 
megakadályozni nem lehet. Hozzá tartozik a történethez, 
hogy a program az adott esetben is , tucatprogram" volt, 
nem pedig egyedi fejlesztés. 

A következő számban mesélek még egy keveset a többszö- 
rözésről, majd az átdolgozásról, amely szoftverek esetében 
szintén speciálisnak mondható. 


Addig pedig Boldog Mikulást! 
Dr. Dudás Ágnes 


" Faludi Gábor meglátása szerint a másolatra vonatkozó határozatlan időre szóló bérleti jog kikötésével is megállapítható helyes jogértelmezés 


mellett a regionális jogkimerülés. 
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